Do you need payment orchestration for fallback?

In practice, yes. Fallback needs several acquirer connections, normalized decline codes, routing rules and credentials usable across providers. Building all of that with custom code for each provider is possible, but expensive to maintain.

The building blocks

• Connections to more than one acquirer for the same methods and markets.
• A common model for decline codes, since each provider returns its own.
• Rules that decide, per code, whether to retry and where.
• Tokens or credentials valid on every route, so the customer does not re-enter card details.
• Limits that respect scheme retry rules.

Why one layer helps

When these pieces live in separate integrations, every new provider multiplies the work. A single layer that connects once and routes everywhere keeps the logic in one place, so adding a provider adds a route rather than a project.

What it means for payment operators

On the NORBr platform, routing rules, fallback policies and return code mappings sit in the same Console, per merchant account. The Vault token is reusable across configured providers, and exclusion rules refine which contract handles which case. Your merchants configure fallback themselves, and you keep the defaults and boundaries, without building a separate layer for each provider.