Skip to main content

Fallback MID

A Fallback MID is a backup merchant configuration that Revup can use when the primary MID fails during the payment process.

When a Fallback MID is configured, Revup can automatically retry the payment using the alternative processing configuration instead of requiring the customer to submit the payment again.

For more information about MIDs and how they are configured, see MIDs.

How it works​

The fallback flow starts when the payment attempt using the primary MID fails.

If a Fallback MID is configured, Revup automatically initiates a second payment attempt using the fallback configuration.

The fallback attempt is performed automatically, so the customer does not need to manually retry the payment.

Only one fallback attempt is made for each payment transaction.

Payment result​

When a fallback is triggered, both payment attempts are included in the callback sent to the configured redirectUrl.

The callback contains two transaction objects:

  1. The first transaction represents the failed attempt using the primary MID.
  2. The second transaction represents the fallback attempt.

The fallback transaction can have one of the following statuses:

  • success
  • failed
  • in_process

You can identify the fallback transaction using the isFallback field.

For example:


[
    {
        "transactionId": "first-attempt-id",
        "transactionStatus": "failed",
        "isFallback": false,
        "mid": { ... }
    },
    {
        "transactionId": "fallback-attempt-id",
        "transactionStatus": "success",
        "isFallback": true,
        "mid": { ... }
    }
]

In this example, the first attempt failed using the primary MID and the second attempt succeeded using the Fallback MID.

Handling fallback transactions​

Your backend should process all transactions included in the callback payload.

Do not assume that the first transaction represents the final payment result when a fallback is configured.

Instead:

  1. Process each transaction in the callback.
  2. Identify the fallback transaction using isFallback.
  3. Store both transaction attempts if your application keeps transaction history.
  4. Use the result of the fallback attempt when determining the outcome of the payment.

For example, if the primary attempt fails but the fallback attempt succeeds, the payment flow has successfully completed.

When the fallback also fails​

If the fallback attempt also fails, no additional fallback attempt is made.

The payment is considered failed after the primary and fallback attempts have both failed.

The flow is therefore:

Configuring a fallback MID​

A Fallback MID must be configured in the Revup Back Office before it can be used.

The fallback configuration includes the required PSP credentials and routing configuration.

The exact configuration depends on your Revup and PSP setup.

info

Contact your Revup team if you need to configure or change a Fallback MID for your account.

Fallback MID and the payment result​

Because a fallback can produce multiple transaction objects for a single payment attempt, your application should be prepared to handle more than one transaction in the callback.

For general information about callbacks, transaction statuses, and handling payment results, see Handle the payment result.

Fallback MID and notifications​

The fallback mechanism does not replace Revup transaction notifications.

Notifications should still be processed according to your normal transaction-handling flow.

For more information, see Notifications.