How smart payment page can improve transaction success rate of a payment gateway

Payment page is the page of a payment gateway which collects card details from a buyer. It is a critical component in determining transaction success rate of the whole system. In this blog I am trying to capture all the work which we can do to make it smart.

Audiences: All payments enthusiasts, architects, developers, CIO/CTOs of payment firms are welcome.
Scope: How payment page can be made smarter to increase transaction success rate.

Here is a list of workable action items, follow this and increase transaction success rate of your payment platform.

1. Page size: This aspect can be very important mainly in India and other developing countries where internet infrastructure is not very strong. If payment page is not light, it will take time to load, and here comes chances of transaction failure. Please consider following for size of a payment page:
1. Remove unwanted/less desired images/logos
2. Change/remove images with improper size/format
3. Remove unwanted java script/CSS files
4. Remove commented/hidden code
   
   
2. Responsiveness: By responsiveness I mean following:
1. The page should be adaptive to changes in web-browser window. It should change placement and alignment of constructs on the page. This becomes very important when your page is supposed to be opened from mobile phones, tablets, desktops and machines with different size of screen
2. All the validations for card details should be done using Java script or AJAX calls to server. There should not be any validation performed at server side only, because if such a validation fails it will take time for the user to see the updated page after a round trip to the payment server
   
   
3. Dynamic methods of payment and payment types: A method of payment can be card association, or a particular net-banking bank. For example Visa and MasterCard are two methods of payment. Payment type can be Credit/Debit card or net-banking. When the buyer is redirected from merchant system to the payment page, there are various possible options:
1. Displaying only the MOP/Payment type selected by buyer at the merchant web site and hiding all other payment types/MOPs
2. Displaying all the supported payment types/MOPs for the merchant, but by default selecting/highlighting only the method of payment selected by buyer at the merchant web site
3. At transaction level merchants should be given option to choose method of payment based on transaction level flags, such as currency, transaction amount, product type, domestic or international card, etc
   
   
4. Handling a page refresh: You know that when you make online payments you read one thing for sure.... "Do not press stop/refresh/close button". True, in some cases payment gateways cannot help to handle this scenario and if the user presses the killer button, the transaction will fail. But a payment gateway should give due diligence to this case, because its a direct killer. The payment page should be tested properly for the following things:
1. There should be be any issue if a user presses refresh at the payment page
2. If the user is redirected from payment page to some other payment platform and user does not return after an interval, try to perform a status inquiry with the outside payment platform to resolve the status. Do not just say a session timeout or web-browser closed
   
   
5. Look and feel: Look and feel of the page needs to be nearly same to merchant e-commerce platform, because this will keep the buyer at home with merchant. The buyer should not be surprised by the new payment platform page which is totally different from merchant's web-site theme. You can do the following basic things:
1. Keep logo of merchant at payment page
2. Color schemes of payment page should be similar to merchant's
3. Business name of merchant should be clearly written on the page
   
   
6. Number of clicks: More time user takes to complete a transaction, less are the chances of transaction being successful. More number of clicks also introduces more number of errors. Do not have many boxes for prompting the user to enter information. You can detect payment type and method of payment from entered card number automatically. Try to fill some boxes from the information supplied by merchant in the payment request. Do not take many confirmations from user
   
   
7. One-click checkout: One click checkout or quick checkout is the ability of buyer to choose a card from a list of cards (previously saved cards by the same buyer) and proceed for the transaction. The user is not supposed to enter all card details again. This enhances user experience, reduces the overall transaction time and hence more success rate
   
   
8. Cancel button/link: You should not prompt the buyer for cancelling a transaction by displaying upfront a big clearly visible cancel button, instead a link to merchant website can be given with text something like ...."Click here to go to www.merchant.com"
   
   
9. Multiple support payment pages: By support pages, I mean any other pages of a payment gateway which support the main page in completing the transaction. You can try to avoid these pages, if these are mandatory for some reason, then try to have all that content in the main payment page only. Following are some examples of support pages:
1. Page for shipping/billing information
2. Page for order detail
3. Page for Surcharge information display
4. Page for EMI scheme display
5. Other confirmation pages
   
   
10. Supported web clients: Today we have different types of clients, like different web-browsers, different mobiles and tablets. A payment gateway needs to be tested for all the possible clients. The payment page can look defaced and distorted with some clients. Some times validations do not work the same way with all the clients. Some times SSL certificate of payment page does not work well on all the clients.

Follow Payment Technologies for more updates.

Note: I have tried to be comprehensive, and I agree that I may have missed something very important also. I request you to put in comments if I have missed something. I want this page to capture all the possible things we can do to make the payment page smarter.

Thanks for reading. Feel free to comment

How to improve payment gateway transaction success rate

Transaction success rate for a payment gateway is critically important, and there are various ways to improve. The best option is to analyze your payment gateway and identify where the transaction is dropping.

In this blog I am trying to present some techniques to improve success rate, and all of these techniques are applicable to almost all payment gateways. Here is the list:

1. Payment gateway integration: All merchants do not have skilled technical team to integrate with payment gateways. Payment gateways can do the following things to smooth the integration process.
   
   a) Simplify integration: This can be done by providing proper documentation, simple use cases, examples, sample codes in different technologies, avoid any complex integration steps be completed by merchant.
   b) Integration API's: A payment gateway can provide integration API's for different technologies/programming languages and common eCommerce platforms. Merchant should be able to paste the API's and get started.
   c) Integration testing: If something is not tested, it will fail. Each merchant should perform testing of integration by going through a UAT, which payment gateway should provide. The UAT should be comprehensive by having all the different possible cases of handling approval and failure.
   d) Integration support team: A payment gateway should have a team of skilled professionals to support merchants integrate.
   
   Here is another post of mine about how to do better integrations for best success rate.
   
   
2. Improper validations: For security reasons there are validations at various steps. If validations are not proper then at any step a valid transaction can be flagged as invalid, and hence will be dropped. Here are some important points in this regard.
   a) Merchants should test all validations when they get postback from payment gateway after a transaction is completed.
   b) If a merchant posts an invalid but optional field to payment gateway. Payment gateway should not reject the transaction. Since the field is optional a payment gateway can try to normalize the value.
   c) Send email to merchant for each invalid transaction, send proper logs in the log system to later see and improve.
   d) Less is the number of mandatory fields, the better it is.
   
   
3. Smart Payment Page: Payment page is the page which collects card details from buyer. There are various features of a smart payment page. Lighter is the page, fast it will load, more mobile friendly it will be. It will reduce refresh of payment page by user. Internet infrastructure in India is not very sound, and a lighter page in this case will win. Here is more about a smart payment page - Smart Payment Page
   
   
4. One click checkout: Different payment gateways call this feature differently. It allows the buyer to save card details on payment gateway and all subsequent transactions only require the buyer to enter CVV. It will speed up the checkout process and will result in better success rate and user experience
   
   
5. Intelligent routing: Payment gateways usually integrate with many payment acquirers/processors. Each acquirer serves some services better than others. Here are some examples:
   a) It can improve success rate by providing more number of methods of payments (card types, etc).
   b) A transaction failed on one acquirer may pass on another.
   c) If one acquire is down for some reasons, other acquirer will still be able to process transaction.
   d) International transactions, dynamic currency conversion, tokenization, 3DS authentication and other such services are not supported by all acquirers
   
   
6. Segregation of 3DS process (MPI) from authorization: MPI is responsible for cardholder authentication using 3DS. It is technically possible to segregate this service from authorization service. It will allow flexibility and control in intelligent routing of transaction. All acquirers in India may not support this feature
   
   
7. Handling a failed transaction: If a transaction failed with one card (method of payment) the payment gateway should prompt the user to use some other card (or a different method of payment) and complete the transaction. If the transaction failed for some internal technical reason with one acquirer, payment gateway may try to complete the transaction with some other acquirer
   
   
8. Number of methods of payments: More is the number of methods of payment, more are the options available for the buyer to use, more are the chances of transaction to success. It will also give more flexibility and control to intelligent routing
   
   
9. Reduce transaction time: Scalability of payment gateway is very important, it should be an enterprise solution with minimum latency, even under load. The time window after starting a transaction and its completion should be minimum
   
   
10. False positive: Some times the fraud and risk prevention system can flag a valid and authentic transaction. It is known as a false positive. You need to do proper analytics and checks that it should not happen
    
    
11. Status inquiry: Some times it happens that the transaction is successful, amount is deducted from buyers account but merchant does not get confirmation about it. A status inquiry web service from payment gateway can allow the merchants to detect such cases. Notifications can also be provided by payment gateway to handle this case. In order to complete the process the right way, the payment gateway should also be consuming such status inquiry service from acquirers, mainly for net-banking transactions
    
    
12. Redirects and forwards: Avoid internal (and sometimes external) forwards and redirects. Try to achieve the same via a server to server call or with some other alternates. Less is the number of clicks/steps/legs/time/forwards/redirects/internal errors, more will be the success rate.

Follow Payment Technologies for more updates.

You are welcome to comment and inquire more. Thanks for reading. Feel free to comment

Payment Gateway Development Guidelines

This is to brief you about best practices in developing payment gateway, here I am not providing low level details. In one way this list can be long, but at a high level I want to list 10 best practices or rule of thumb.

My objective here is to make the payment gateway deliver better success rate, be secure, fail safe, maintainable and scalable. This way you should be able to create a payment gateway which will cater requirement of future.

Here you go...

• Modular and plug-gable: A payment gateway has to integrate with different payment processors or acquirers (modules), a transaction has to be routed to other core modules also, for example – dynamic currency convertor, fraud and risk preventer, sending emails/SMS, tokeniser, sending online real time notifications etc. All of these features when added as a modules make the payment gateway simple, scalable, secure and maintainable. Having different modules for different features also allows parallel processing and best utilization of available resources, and in all this helps in giving better transaction success ratio
  
  
• Defensive programming: By this I mean http://en.wikipedia.org/wiki/Defensive_programming and other techniques to eliminate any possible bugs, modular interdependencies, security issues and unforeseen scenarios
  
  
• Secure application development processes: Application development process needs to include automated and manual security testing, code review etc
  
  
• Poor database can kill your payment system – consider going through https://www.onlinepaymentsindia.com/2013/12/databasekills.html
  
  
• Single entry/exit points – Each module should have one and only one entry/exit point. This way you can apply proper access controls at function/module level. This would also allow you to handle errors/exceptions at one central place, via a single route
  
  
• Request/Response contract with client: For different services that your payment gateway is giving to merchants, try to have a limited set of urls that merchants/users can use. Do not have a long and confusing set of URLs or parameters. Request and response contact with merchants should also be clear and concise. Type, minimum length, maximum length, allowed characters, possible values should clearly be defined. This will ease payment gateway integration, your merchants may not be having a big technical team to handle technicalities of you system. This simple is payment gateway integration, more is transaction success rate
  
  
• Batch modules: End of day processing, reconciliation, reporting, settlement and some analytics are usually done in batch mode. You need to decide on your batch modules and processes in initial phase of development, if not then in the end this will turn out to be a big hurdle. If you are using java, then spring batch can be good for batch processing. Before finalizing the data model, consider batch modules also. Click to see batch modules details
  
  
• Crypto: This is sometimes a challenge, because it involves key management, secure storage of keys and card holder’s data. This is usually target of attackers also. There are many different security strategies possible. At a high level following considerations can be good:
• Divide keys in parts and keep at different physical/logical locations
• Encrypt keys
• Using unique key per transaction can help
• Keep tight access controls on keys and key encryption keys
• Keep rotating the keys
  
  
• SOA: Since it is a modular software by nature, service oriented architecture can lend reusability and performance. We have front-end, back-end services, batch modules etc. SOA glues modules loosely, with high coherence and low coupling/inter-dependencies
  
  
• Consider different industries: A payment gateway is not only about e-commerce card not present transactions, it is also about mobile payments, retail – card present transactions, EMV transactions, traditional POS transactions etc. Your data model, access control, and application design needs to consider this.

Follow Payment Technologies for more updates.

You are welcome to reach me for any suggestions and queries. Thanks for reading. Feel free to comment