FailOver Routing

Introduction#

In the world of online payments, the success or failure of a transaction can have significant implications for both businesses and customers. Payment failures can be broadly classified into two categories

⚡️ Customer-related failures#

Customer-related failures typically result from unavoidable issues such as incorrect OTP or CVV, payment timeouts, and other similar errors.

⚡️ Non-customer-related failures#

In contrast, non-customer-related failures occur at the payment gateway level and can arise due to factors such as server downtime, maintenance, connectivity issues, or an overloaded gateway.

How to address Non-customer-related failures#

To address non-customer-related payment failures, it is crucial to build a smart routing mechanism that can help route transactions appropriately and improve success rates.

We have implemented Failover routing to switch between payment gateways in case of a failure. This type of routing is straightforward and reliable, allowing the system to switch to a backup gateway quickly. Failover routing is ideal for businesses that need to have a backup plan in place to ensure that their transactions can still go through even if their primary payment gateway experiences a failure.

User Flow for Failover Routing#

The payment process is a critical aspect of any business, and ensuring a smooth and seamless payment experience for customers is paramount. At our system, we have implemented a failover routing mechanism that helps to ensure that payment transactions are successful, even in the event of a payment gateway failure.

To understand how the failover routing mechanism works, let's take a look at the user flow that occurs during the payment process:

Transaction Initiation: When a payment transaction is initiated on our system.
Transaction Success: If the transaction is successful, our system will redirect to the success URL provided during the payment process. The success URL will contain query parameters that include the relevant information about the transaction.
Transaction Failure: In case of any errors or failures that may occur during the payment process, our system will categorize the errors and redirect them to an intermediate page. This intermediate page will provide detailed error messages and reasons for the failure, allowing the customer to take appropriate actions.
Intermediate Page: The intermediate page will contain two buttons:
- The "Cancel" button will redirect to the failure URL, which is also provided during the payment process. This button will not allow any retry attempts.
- The "Retry" button will be enabled based on the error categorization. If the error is determined to be a "User Error", our system will attempt a retry with the same payment service provider (PSP) that was used during the first attempt. If the error is categorized as a "PSP Error", we will retry with another PSP as per the ranking provided.

This payment flow ensures a seamless payment process for customers, while also providing a reliable and fault-tolerant payment system for merchants. By implementing failover routing, we are able to minimize the impact of payment gateway failures on our payment system, providing peace of mind to both businesses and customers alike. This payment flow ensures a seamless payment process for the customers, while also providing a reliable and fault-tolerant payment system for merchants._

Configuration of Route from Admin Dashboard#

Parameter for FailOver routing#

To perform FailOver Routing on a transaction, below is the additonal payload that needs to be added in the Init Payment request API.

    "routing_enabled": true, //To enable routing. datatype: boolean
    "routing_params": {
        "type": "failover", //Identifier on type of routing. datatype: string
        "route_ref": "Route_2P0qQgyROrPuzJDZebGSIsfYsX4",  // Route reference that can be created from Dashboard. datatype: string
        // if you add route_ref in the payload you can ignore the below parameter
        "data": [
            {
                "channel_key": "GBPRIMEPAY", //Channel name from our docs. datatype: string
                "method_key": "GBPRIMEPAY_CREDIT_CARD", //Method name from our docs. datatype: string
                "rank": 1 //Rank or priority of the route. datatype: integer
            },
            {
                "channel_key": "OMISE",
                "method_key": "OMISE_CREDIT_CARD",
                "rank": 2 
            }
        ]
    }

Response#

The API response will contain a redirect URL where user action can be performed, a sample response payload is given below

{
    "is_success": true,
    "redirect_url": "<< Redirect URL for making the payment >>",
    "channel_order_ref": "<< PSP transaction reference >>",
    "merchant_order_ref": "<< Your reference  >>",
    "order_ref": "<< PortOne transactions referer >>",
    "message": "",
    "deep_link": "",
    "additional_data": null
}

Here are different scenarios assuming a 2 level routing request#

Scenarios	PSPs Config (Primary & Secondary)	No of Tries	Which PSP Triggered in each	UX flow in Steps	Final Outcome	Response
Happy Scenario - with 3DS	PSP A & PSP B	1	PSP A	1. Payment Initiated 2. Redirect to PSP A 3. 3DS Check 4. Redirect to the Success URL	Payment Successful	Webhook & Redirection - PSP A details
PSP Error - Primary Fails	PSP A & PSP B	2	PSP A & PSP B	1. Payment Initiated 2. Redirect to PSP A 3. PSP A Fails 4. Redirect to Intermediate Page 5. Retry with PSP B	Payment Successful with PSP B	Webhook & Redirection - PSP B details
PSP Error - Secondary Also Fails	PSP A & PSP B	2	PSP A & PSP B	1. Payment Initiated 2. Redirect to PSP A 3. PSP A Fails 4. Redirect to Intermediate Page 5. Retry with PSP B 6. PSP B Fails 7. Redirect to Intermediate Page 8. Cancel	Payment Failed with no Retry Attempts	Webhook & Redirection - PSP B details
User Error (e.g OTP incorrect)	PSP A & PSP B	2	PSP A	1. Payment Initiated 2. Redirect to PSP A 3. 3DS Check 4. Redirect to Intermediate Page 5. Retry with PSP A	Payment Successful with PSP A	Webhook & Redirection - PSP A details