Wednesday 24 June 2020

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:


Thanks for reading. Feel free to comment

5 comments:

Potential Micro-Services in a Payment Gateway

This post is particularly important for you if you want to: Do technology transformation to break a monolith payment solution to micoservi...