|
|
|
Designing and Building Payment Applications
DESIGNING AND BUILDING PAYMENT APPLICATIONS
By Robert Levings, President, EasyPay123
Unless you are using an off-the-shelf shopping cart application, chances are that you or your developer will be customizing at least some element of your payment application to meet your specific needs. Your payment application may be simple or it may be complex; either way, following the right sequence of events and taking advantage of available technology will help increase customer satisfaction; reduce development costs, payment-related errors and time to market; and provide you with a more functional application.
The following article highlights the key steps involved in designing, building and launching payment applications. While it is written from a developer's perspective, it will equip the merchant with information that you can use to when you are interacting with your developer throughout the process. It is part of a series of articles offered by EasyPay123 to help merchants understand the many facets of processing credit card payments.
Step 1: Understand User Needs
Understanding user needs is a necessary starting point for the development of any payment application. Documenting how the user will interact with the application and all of its various features ensures that all parties can agree on what the final product will look like and how it will operate. Some of the questions that must be answered at this stage include:
Marketing CompetitorsThere are thousands of business opportunities online. Most of them require some capital .....
* How will payments be accepted (online, phone-in, IVR, etc.)'
* What customer data is to be captured (e.g. name, phone #, address info, etc.)'
* What supplemental data will be captured (e.g. demographics, questionnaire, etc.)'
* Which data fields should be made 'required' on the interface'
* What error detection/correction or data validation scripts will be used (e.g. MOD10 credit card number validation, date/dollar format, etc.)'
* Do any calculations need to be made on the interface'
* What will the look and feel of the interface be (graphics, text, colors and layout)'
* Will access to the application be restricted by IP address or username/password'
* Will the results of the transactions update a database in real-time or be made accessible to a third party application/data-base at some point after the transactions take place'
* How will the credit card data be input (keyed, swiped, touch screen, etc.)'
* What content should be put on the response/receipt page'
* How will the customer/merchant receive an email receipt (if desired)'
* What will the contents of the emailed receipt be'
* What bank(s) will be used for merchant accounts'
* Where will the application be hosted'
* How will the payment form be secured'
The answers to these questions should be captured in a specification document so that the merchant can review and comment. This step will reduce development time and cost, and also increase merchant satisfaction with the project.
Step 2: Design the Interface
Designing the user interface is always 'part art/part technology' and will vary greatly depending upon the application. It should be driven primarily from the user needs defined above. In addition, technical considerations, such as the target operating system, hosting environment and development language must be taken into account. These decisions are the 'meat and potatoes' of most developers' business, so little discussion is necessary here. An interface mock-up is useful so that users can provide input and test out the application (some payment gateways provide developer environments so that a transaction can be accurately simulated with the application prior to 'going live').
You may want to include any number of scripts in the interface to reduce errors and improve its functionality. Some that you may find useful include:
(a) MOD10 Check: Uses the Luhn algorithm to determine whether the credit card number is valid or not. Reduces transaction time. Could reduce merchant cost if gateway charges for failed credit card numbers.
(b) Order Number Generator: Generates a unique numeric order number that can be posted with each transaction. With the 'reject duplicate order number' option turned on (if supported), it nearly eliminates the risk of duplicate transactions being processed by the gateway.
(c) Required Fields: Disables the ability to submit a transaction unless all required fields are completed on the order form. Ensures all necessary / desired data is posted to the payment gateway.
(d) Double Submit Prevention: Disables the ability for the user to click the 'Submit' button again while a transaction is still processing. Reduces the risk of an erroneous double submission of an order.
(e) Email Validation: Ensures that an email address is in the format XXXXX@YYYY.ZZZ. Reduces the risk of incorrect emails being entered.
(f) Complete If Left Empty: Automatically populated a specific data field if the user chooses to leave it empty (e.g. inserting 'not specified' into the address field).Ensures that fields that are required by the gateway are populated with an acceptable value.
(g) Alpha / Alpha- Numeric / Numeric Only: Issues an error message if the user enters the wrong data format. Reduces the risk of data entry errors.
(h) All Caps / Lower Case: Issues an error message if the user enters the wrong data format. Reduces the risk of data entry errors.
Step 3: Integrate to the Payment Gateway
Integrating the payment gateway to an application (such as a website or billing system) can vary greatly in terms of the complexity involved. In general, the following steps will apply:
1. Integration Method Selection
Most payment gateways have many integration methods depending on the type of interface sending the transaction, where that interface is hosted (i.e. operating system) and how complex the integration is. For example, some implementations may use a simple form post to the payment gateway, whereas more complex ones may require the use of an API.
Mapping out the data flows and system requirements for the application against the payment gateway integration methods will help determine the appropriate method. Generally speaking, use of an API provided by the gateway provides the most flexibility, but can be more complicated to integrate and maintain.
2. Data Field Posting Configuration
In this step, you should ensure that you are passing all of the required and optional fields from the interface to the gateway using the correct syntax. Required fields are the minimum ones necessary to complete the transaction. Optional fields contain useful supplementary data. They must be posted to the gateway using the syntax dictated by your gateway provider.
3. Response File Interpretation
Once the fields are posted, testing must be done on the response mechanism(s) to ensure that they correctly interpret all possible response outcomes from the payment gateway (e.g. approvals, declines, system errors, etc.). This involves simulating the various outcomes and making sure that the correct response values are mapped to the variables, and that everything displays properly in the response pages and email templates (if available).
In some cases, the payment gateway may actually display the variable name that has been used for a specific data field in the response page (e.g. if you use 'CustName' as the variable, this may be what is displayed to the user in the response page, email, etc.). Wherever possible, try to use 'customer-friendly' variable names rather than cryptic ones to avoid confusion on the part of the user.
4. Fail Safe Development
Put fail-safes in place to compensate for internet connectivity failures that might result in the customer not getting a payment response from the gateway. This involves working through the logic of how a customer processes a transaction and receives notification of the transaction to identify possible points of failure (e.g. what would happen if Internet connectivity failure occurred immediately after a customer posted a transaction to the payment gateway but before the response page was returned' How does the customer know what the status of the transaction is').
Fail-safes can take many forms. EasyPay123, for example, has a Get Transaction Status feature that allows the application to query Skipjack based on unique order number to determine (a) whether the transaction is in the system, and (b) if it, what its status is (e.g. approved, declined, settled, etc.). Once the status is known, the application can be programmed to determine the correct course of action to take automatically.
5. Third Party Linkages
In some instances, there may be a requirement to pass transaction data to a third party application, either ......
Read More ...
|
|
