Cascade payment processing

Overview

Payments could sometimes fail due to different reasons. For example, while a payment is being processed by a provider or a bank, technical issues may occur, or processing of the payment may take too long, or a customer's card limit may have been reached.

The JetPay payment platform supports cascade payment processing that includes additional attempts to process a payment if your initial attempt to process the payment was unsuccessful. In any of the above cases, the cascading option enabled allows the payment that cannot be processed properly by a provider to be rerouted to an alternative providerYou can use the cascading option for both one-step and two-step purchases with authentication by using 3‑D Secure as well as without authentication.

Using the cascading option doesn't require to update the merchant web service because workflows of cascade payment processing and regular payment processing are the same for the merchant web service. The following section discusses in more details the workflow of cascade payment processing.

Setup and configuration

To implement the cascading option in your web service you need to contact your JetPay key account manager and discuss the possibility of implementing the option, and then test and deploy cascade payment processing with the JetPay technical support.

Workflow

Payments with the enabled cascading option are initiated in the same way as regular payments. Your web service is required to send a request for purchase to initiate an attempt to process the payment by using Payment Page. When the payment platform accepts the request, Payment Page is displaying to a customer for entering card details. The payment platform processes the initial attempt to process the payment, and in addition the 3‑D Secure authentication may be required. If the customer is charged for this attempt, the payment platform sends a callback with the payment results and the success payment status. If the customer isn't charged for the initial attempt, the payment platform keeps processing the payment that may contain one or more additional attempts to process it.

Until the customer is charged for one of processed additional attempts before the limit on the number of allowed attempts has been reached, the payment platform initiates a new additional attempt. If the new additional attempt doesn't require 3‑D Secure authentication, there is no need any customer and web service involvement. If the 3‑D Secure authentication is required, Payment Page displays a page with customer card detailes, information about unsuccessfull attempt and Retry button. If the customer confirms one more additional attempt to process the payment, the payment platform keeps processing the new additional attempt with new 3‑D Secure authentication. The payment status is set to one of following ones: awaiting_3ds_result, awaiting_redirect_result or processing.

Payment processing with the enabled cascading option is completed in the same way as regular payment processing. The payment platform sends a callback with the success payment status, if the customer has been charged for one of processed additional attempts. The payment status is set to decline, if the customer hasn't been charged for one of processed additional attempts before the limit on the number of allowed attempts has been reached.

The following diagram provides the detailed picture of a one-step purchase processing with the cascade option enabled and 3‑D Secure 1 authentication included.

Figure: Payment processing with enabled cascade option and 3‑D Secure 1 authentication included

  1. The payment platform sends the purchase request to the provider service.
  2. The provider service determines whether the 3‑D Secure 1 authentication is required. If the authentication is required, the provider service sends the customer redirect data to the payment platform. If the authentication is not required, ignore the steps 3‒8 and go to the step 9.
  3. If this is the initial authentication, proceed to step 4. If this is a re-authentication:
    1. the payment platform displays card details, information about unsuccessful attempt to the customer and asks the customer to confirm one more purchase attempt with the same card details
    2. the customers agrees to one more purchase attempt
  4. The customer is redirected to the authentication page.
  5. The customer goes to the authentication page and completes the required steps.
  6. The issuer authenticates the customer and then sends the authentication result to the payment platform.
  7. The customer is redirected to the checkout page.
  8. The payment platform sends the request to continue the payment processing to the provider service.
  9. The provider service processes the request and performs one of the following steps:
    • if the purchase is declined, the provider service sends the information about the decline to the payment platform, then the payment platform initiates a new attempt to process the payment
    • otherwise the provider service sends the purchase request to the issuer, then the payment is processed as usual

Callback format

In card payments, payment processing with enabled cascading option uses the standard format for callbacks with payment results. For more information, see Callbacks in Payment Page.