Skip to main content
A charge can fail at one payment gateway and still succeed at another, for example when one gateway has an outage or declines for a reason that is specific to that gateway. With fallback payment gateways, you list backup gateway accounts in the request. If the primary gateway does not complete the charge, PCI Booking tries the backups one by one until one succeeds. Fallback is available in two places: Each fallback entry points to one of your stored payment gateway credentials.

​
How It Works

  1. PCI Booking sends the charge to the primary gateway.
  2. If the charge does not succeed, PCI Booking checks the decline reason (RejectReasonCode).
  3. If the reason allows a retry, PCI Booking sends the charge to the first fallback gateway, then the next, in the order you listed them.
  4. PCI Booking stops at the first gateway that succeeds and returns that result.

​
When Fallback Is Not Used

A retry at another gateway cannot fix some declines, and repeating the charge could harm the cardholder or your merchant accounts. PCI Booking does not try any fallback gateway when the primary gateway declines with one of these reject reason codes: Fallback is used for any other failure, including declines with no reject reason code.

​
Universal Payment Gateway and Payments Library Compared

In the Payments Library, fallback applies to card payments, Apple Pay and Google Pay, which are processed through a payment gateway. PayPal, BankPay and UPI payments do not use fallback gateways. In the Payments Library, each fallback gateway can have its own gateway parameters and its own 3D Secure setting (Pass3DSData), because gateways differ in what they need.