Skip to main content

Fallback MID

A Fallback MID is a backup merchant configuration that Revup uses when the main MID fails during the payment process. This mechanism ensures higher transaction success rates by allowing the payment to be retried automatically with an alternative configuration, often tied to a different PSP or routing logic.


How it works

When a payment attempt fails using the primary MID—for example, due to a 3DS configuration error or a restricted card—Revup immediately initiates a second attempt using the Fallback MID, if configured. Both attempts (initial and fallback) are logged and included in the callback to the redirectUrl, allowing merchants to track the full flow.

The structure of the response will contain two transaction objects when a fallback is triggered:

  • The first object reflects the failed attempt with the main MID.
  • The second object reflects the result of the fallback attempt, which can be either a success, failure, or in-process status.

You can distinguish the fallback transaction using the field:

"isFallback": true

This approach is fully transparent to the end-user and avoids manual retries. For example, a response to the success redirectUrl may look like:

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

Key Considerations

  • Fallback is only triggered when the first attempt fails.
  • Merchants should always process all transactions listed in the callback payload to record both attempts.
  • Only one fallback attempt is made per transaction. If the fallback also fails, the payment is considered failed.
  • The fallback MID should be pre-configured in the Revup backoffice with compatible PSP credentials and routing.
info

This mechanism provides resilience for production traffic and improves authorization rates by adding a secondary processing path.