How payment gateway can handle refresh and back button for better transaction success rate

Target audience for this post are payment gateway(or other payment solution) software developers. I am detailing how to handle the back/refresh button so that the the payment transaction gets successful.

This is typical problem which can occur in any web application, for example resubmitting a form can lead to creation of a duplicate order. These kind of issues pop up more when user has poor internet connection, slow server due to over load or other reasons etc

As a payment gateway software developer you must have placed a text like "Please do not refresh the page and wait while we are processing your payment". This is shown to customer while the payment is under process at various pages. If the customer attempts to refresh or back button then the payment might fail or there may be a duplicate payment. There can be other errors leading to bad user experience and loss of business to both merchant and payment gateway because of a failed transaction.

Following can be the scenarios where a back/refresh button can create a problem:

• Scenario 1 - Merchant to payment gateway - This is when a user is being redirected by a merchant from merchant web/mobile application to payment gateway page, this redirection is usually achieved by a POST from merchant to payment gateway system. This is usually the first step in the payment process
  
  
• Scenario 2 - Payment Gateway to Bank/3D Secure Page - This is when a payment gateway redirects the user via POST request from payment gateway to a bank (or third party) for 3D Secure page or net-banking page of a bank
  
  
• Scenario 3 - Bank to Payment Gateway - This is when a third party (like bank for 3D Secure Page or net-banking) redirects the user to payment gateway after completing authentication at the third patties end
  
  
• Scenario 4 - Payment Gateway to Merchant Website - This is when a payment gateway redirects a user using POST request from payment gateway to merchant website. This is usually the last step in the transaction flow indicating success or failure of the transaction to merchant system

Following I am giving some generic solutions to handle different kind/stages of refresh/back button

• Screen dim after sometime: You know that mobile phones and devices dim the screen after inaction of sometime and exactly at this time the user presses the back/refresh button. In your text put something like "This can take a few minutes". So that the user is having patience. Well, all users might not read it but it would help in certain cases
  
  
• Keep your page light weight and fast: Take minimum time in loading your page and do the processing fast in payment gateway so that the overall time required reduces to significant extent
  
  
• Use status inquiry where possible: Do not duplicate a transaction, just check database of the transaction already exists or you can also make use of status inquiry provided by almost all payment systems/processors
  
  
• Post/Redirect/Get Design pattern - Where ever possible try to use Post/Redirect/Get design pattern. By using three different pages for submission, processing and displaying result of an action
  
  
• Keeping a unique id in session - In certain cases you might want to keep a unique value in session variable and check if it is re-submission before processing a duplicate request, using this logic you can ignore second third re-submission
  
  
• Do not disable back/refresh button - Do not attempt to do some tricks to disable use of back/refresh button because. That is not the way to go because that violates user experience, all web-browsers do not support such tricks
  
  
• Keep making status inquiry - You can keep making regular short internal status inquiry to payment processor/bank in the back-end system and once you get a success flag for a transaction just send a server to server notification to merchant's return URL. This can be done even if the user closes the web-browser after completing the transaction and before returning to merchant web application
  
  
• Creating a duplicate payment transaction - Certain online merchants may want to even do a duplicate transaction in cases where status of the transaction is not clear, this can be done on configuration bases and can diff for different merchants. If there are two duplicate transactions then one of them can be reversed/refunded. While this kind of requirement may not be applicable to all merchants. This may introduce manual interventions in reversals/refunds etc. It can add value in certain cases by not missing a sale
  

The above mentioned steps can help a payment gateway but may not eliminate such cases because a payment gateway does not have full technical control over banks and other financial institutions involved in a payment transactions, and they might be displaying such page without required smartness inbuilt to support such scenarios.

Following are various other ways to keep the transaction success rate high:

Robust payment gateway integration

How to keep best database performance for a payment gateway

How smart payment page improves transaction success rate

Right messaging format for payment gateway integration

Thanks for reading. Feel free to comment

ISO 8583 vs Name / Value Pairs | Payment Gateway Integration Architecture

It is very important to choose the right payment gateway integration design pattern while developing a payment gateway. This is important because it can impact transaction success rate directly (click here to see why). For online card not present transactions, a name/value or key/value pair based messaging format is considered best for payment gateways because it can help in following ways:

A name value pair based message will look like (just an example):

AccessCode = '100GFTJ',
Amount = 10000,
TransactionType = 'AUTH'
Locale = 'en',
MerchTxnRef = 'myorderid01',
MerchantId = 'mymerchantId',
OrderInfo = 'my order description',
ReturnURL = 'RETURN URL of MERCHANT WEBSITE',
Version = '1'
Note: There can be many other fields like above, can depend on transaction type also

1. Loosely coupled because it provides a flexibility in changing client-server contract in future at server end without requiring the existing client to change integration related code
   
   
2. Simplification of the client-server contract because ISO 8583 requires a learning curve and many online merchants may not have that skill or time required to integrate
   
   
3. Similarity to other payment gateways because many big and popular payment gateways are using the same approach. This kind of similarity allows the clients to integrate with your payment gateway without much effort or additional learning curve
   
   
4. Test-ability ease with various scenarios and transaction types, you can run your existing old test cases to validate if the new code will not break any existing clients
   
   
5. Same messaging format with different transaction types, you can keep the URL also same because the client will not be required to change URL for different transaction types. Transaction type can be a name/value pair in the message like TXN_TYPE=AUTH

In case you are developing a payment gateway interface for card present/POS terminal based transactions then ISO 8583 is better because:

1. ISO 8583 is a light weight and compact messaging format, it makes the message size small all POS terminals may not be having a high internet bandwidth and speed to transfer big sized messages to servers
2. A client/merchant will not require a learning curve because offline merchants are provided the POS terminals by the payment gateway company or a technology partner

Click for a quick read about about payment gateway integration for best transaction success rate

Thanks for reading

12 Factor App Guidelines for Digital Payment Solutions

The 12 factor app guidelines have become an important baseline for horizontally scalable & robust microservices. They can also be used as baseline for microservices in digital lending platform or loan management system (LMS) or loan origination system or a payment gateway. These guidelines are particularly important for a financial software solution because you cannot afford to miss payments as a result of fragile technology, these guidelines also help to be more agile and quick in quality releases of new features and bug fixes.

 

Following I am giving a snapshot of the guidelines and a link to potential microservices in a payment gateway and the 12 factor guidelines

https://www.onlinepaymentsindia.com/2020/06/potential-micro-services-in-payment.html

https://12factor.net/

Thanks for reading

You are welcome to comment and share your understanding