Working template: Payment orchestration vs gateway: design routing you can operate

Payment orchestration vs gateway: design routing you can operate

Editorial working template
https://www.ecommerce.spot/en/guides/payment-orchestration-vs-gateway
Reviewed: 2026-10-29

Record your systems, decisions and acceptance evidence. Use this template for the brief, then confirm demonstrated capabilities and unresolved limits in the actual proposal.

Project / owners / date:
________________________________________

Payment orchestration decides which processor should handle a payment attempt. A gateway provides a route for submitting payment requests, although commercial products can combine these roles. Compare the actual operating responsibilities: adding routing only helps when supported payment flows, recovery and reconciliation work together.

1. Reason to add routing
Which evidenced availability or market gap requires more than one processor?
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

2. Capability matrix
Record proven support by merchant account, market, currency and method.
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

3. Routing policy
Specify priorities, conditions, exceptions and the rule version.
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

4. Retry policy
Which failures allow another attempt and how are uncertain outcomes resolved?
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

5. Stored methods and exit
Name the mapping owner and the supported migration or customer-action path.
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

6. Post-payment operation
Identify the original-payment, refund, dispute and payout reconciliation owners.
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

7. Acceptance
Retain expected route, actual route, attempt references, final state and unresolved limitations.
Your inputs / decision:
________________________________________
Evidence / owner / unresolved issue:
________________________________________

Acceptance checklist
[ ] The multi-processor problem and success criteria are explicit.
[ ] Capabilities are confirmed by account, market, currency and method.
[ ] Known failures and unknown outcomes have different handling.
[ ] Authentication and risk policy are reviewed with routing rules.
[ ] Token usability and a supported exit process are established.
[ ] Refund, dispute, payout and cost responsibilities are assigned.
[ ] All attempts remain traceable through order and financial acceptance.

Article references
Stripe: Orchestration overview: https://docs.stripe.com/payments/orchestration
Stripe: supported Orchestration features: https://docs.stripe.com/payments/orchestration/feature-support
Stripe: cross-processor retries: https://docs.stripe.com/payments/orchestration/retries
Adyen: create tokens and import stored payment details: https://docs.adyen.com/online-payments/tokenization/create-tokens
Stripe: payment orchestration vs payment gateway: https://stripe.com/resources/more/payment-orchestration-vs-payment-gateway