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 Rocketpay 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 Rocketpay key account manager and discuss the possibility of implementing the option, and then test and deploy cascade payment processing with the Rocketpay 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 performs the internal request processing and sends it to the provider.
  2. The provider processes the request and determines whether the 3‑D Secure 1 authentication is required. If it's required, the provider sends customer redirection data. If it's not required, the provider forwards the request for purchase to an issuer.
  3. The payment platform sends the message with the customer redirection data to Payment Page.
  4. Payment Page interacts with the customer:
    • If the authentication is required for the first time within the payment processing, Payment Page redirects the customer to the authentication page.
    • If the authentication is required again, a page with customer card details, information about unsuccessful attempt and asking a customer to confirm one more 3‑D Secure 1 authentication with the same card details is displayed to the customer. If the customer confirms, Payment Page redirects the customer to the authentication page.
  5. The authentication page is displayed to the customer.
  6. The issuer authenticates the customer.
  7. The issuer sends a message with the authentication results to the web service.
  8. The issuer redirects the customer to Payment Page.
  9. The preloaded page of Payment Page is displayed to the customer.
  10. The payment platform sends the request for payment to the provider.
  11. The provider processes the request. If the customer isn't charged, the provider sends information about declined payment, and then the payment platform initiates a new additional attempt to process the payment. If the customer is charged, the provider forwards the request to the issuer, and the payment platform keeps processing the payment in the same way as regular payment processing.

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.