The best practices to follow when designing User Self Service applications are as follows:
- Ensure that the information that customers can see and functions customers can perform meet the requirements of your business model.
- If your services are offered only at the supplemental plan level and you have a master plan that is assigned to all new customers by default, then you should not show your master plan to customers.
- If you do not offer inventory items for customers to order, you should not show an ordering section in your application.
- Allow customers to select only the payment methods that your company accepts.
- Provide customers with the ability to perform the required actions for managing their accounts.
Example: Provide a text box in which customers can enter the number of units of a plan to which they want to subscribe.
- Include a Terms and Conditions link from which customers can access information about the general terms or the agreement under which they may use your application.
- After a customer logs in, use the validate_session call at every page load to determine the validity of the session and the user with which the session is associated.
- In every method used to update, switch, or cancel plans, set the do_write field to false before displaying a confirmation page to the customer. This will prevent the plan change from going into effect before the customer confirms the requested change. After the customer confirms the request, you can call the applicable method again with the do_write field set to true.
Constraints
Trigger
The User Self Service process begins when customers visit your website and log in to do the following:
- View or modify their account, billing, or payment information.
- View or modify information related to the service plan(s) to which they are subscribed.
- Submit a payment.
- Place orders for inventory items.
Assumptions
The process descriptions in this document are based on these assumptions:
- You are hosting your own User Self Service applications.
- Your account data is stored in Aria.
Preconditions
- Whitelist your IP Addresses
- Obtain Your Client Number and Authorization Key
- Create Your Direct Post Configuration Set
The Direct-Post Payment Handler (also referred to as Direct-Post) is a tool that you use to secure the pages in your applications on which customers enter credit card and bank account information.
You can create multiple configuration sets to address different User Self Service use cases. Refer to the Create your Direct-Post Configuration Set sections under the specific use cases for instructions that apply to those use cases.
You can use the set_reg_uss_config_params API call to create Direct-Post configuration sets.
Postconditions
The postconditions vary based on the use case involved. Please refer to the section for each use case in this document for specific postconditions