What a payment orchestration RFP should ask: 30 questions

Most payment orchestration RFPs are long and still miss the questions that matter. They ask how many connectors a vendor has, and not whether the three providers you need in Mexico are live. They ask whether routing exists, and not how it decides. They ask about security certificates, and not who owns your saved cards when the contract ends.

This article gives 30 questions, grouped into ten areas, with a note on what a good answer looks like. It is written for heads of payments, CTOs and procurement teams at e-commerce merchants comparing orchestration platforms. Use it alongside our articles on how many PSPs you need per market and single-PSP risk, which cover the strategy behind the purchase.

How should you prepare before writing the RFP?

Write down your own traffic first. Vendors answer in generalities unless the RFP gives them specifics. Include:

• Monthly payment volume and count by country, currency and method.
• The providers you use today and those you want to add.
• Payout and refund volumes, and the rails they use.
• Saved card counts and where they are stored.
• Your must-have dates: market launches, contract renewals, peak seasons.

Then every question below can be answered for your case, and answers become comparable.

Coverage and connectors

1. Which of the providers and methods in our list are live today, in production, for which countries and currencies? A good answer separates live, in development and on request.
2. For each connector, which operations are supported: authorisation, capture, void, partial and full refund, payout, saved cards, 3-D Secure, webhooks? Many connectors support payments but not refunds or payouts.
3. How long does a new connector take, and who pays for it? Ask for recent examples.

Routing and cascading

4. What data can routing rules use? Country, method, currency, amount, card attributes from the BIN, customer group, verification level and recent performance are typical.
5. How are eligibility (what is allowed) and preference (what is best) separated? Mixing the two makes rules hard to reason about.
6. Which failures trigger cascading, and which are never retried? The answer should distinguish technical failures, soft declines and hard declines. Our guide to soft vs hard declines explains why.
7. Can we see, for each payment, which providers were eligible, which was chosen and why? Ask to see a real log entry.

Tokenization and card portability

8. Where are saved cards stored, and under whose PCI DSS scope?
9. Can saved cards be used with every connected provider, or only the one that created them?
10. If we leave, how are card numbers exported, to whom, and how long does it take? Card exports are normally only sent to a compliant receiver: Stripe, for example, transfers card data only to a PCI DSS Level 1 processor that provides its Attestation of Compliance or a Visa registry listing.
11. Are network tokens supported, and with which providers? See our comparison of network tokens and PSP tokens.

Checkout

12. What checkout options exist: hosted page, embedded components, direct API? Each changes your PCI scope and design control.
13. How are local methods presented, ordered and localised by country, language and currency?
14. How does the checkout behave for asynchronous methods such as vouchers, bank transfers and instant payments?

Refunds and payouts

15. Can refunds and payouts go through the same API and routing rules as payments?
16. How are refunds handled for methods that cannot receive money back to the source?
17. How are payouts protected against duplicates after a timeout? Look for idempotency keys and a rule to wait for final status before rerouting.

Data, webhooks and reconciliation

18. What is the webhook delivery model: retries, ordering, signatures, and a log of attempts? Providers deliver at least once and retry for hours or days (Stripe for up to three days, Checkout.com up to eight times), so the platform should normalise this for you.
19. Is there one transaction model and status set across all providers?
20. What reporting and exports exist for finance: transaction level, settlement level, fees?
21. How is approval rate defined: per attempt or per payment? Our article on how to calculate approval rate explains why this matters.

Security and compliance

22. What is the platform’s PCI DSS validation level, and can we see the Attestation of Compliance? PCI DSS applies to any entity that stores, processes or transmits cardholder data, so ask which parts of your stack stay in scope.
23. Where is data hosted and processed, and will you notify us before that changes?
24. How are user roles, access to card data and changes to routing rules controlled and logged?

Operations and service levels

25. What are the service levels for uptime, latency and support response, with which remedies? The EBA’s outsourcing guidelines, written for payment institutions, expect precise quantitative and qualitative targets; that is a sensible bar for anyone.
26. How are incidents detected, communicated and reviewed, and can we see a recent post-incident report?

Pricing

27. What is the pricing model: per transaction, percentage, platform fee, per connector, per merchant account? Model it on your own volumes for three years.
28. What costs sit outside the vendor’s price: provider fees, network token fees, currency conversion, new connectors?

Exit and contract

29. What data do we get on exit, in what format, and within what time? Transactions, routing logs, customers and saved cards.
30. What are the termination rights and notice periods on both sides? The EBA guidelines list termination rights, data access on insolvency and audit rights among standard contract contents, and expect documented, tested exit plans for critical functions.

What should the demonstration include?

Written answers tell you what a vendor says; a demonstration on test transactions tells you what the platform does. Ask every shortlisted vendor to run the same script, with your team watching:

1. A card payment routed by a rule you specify, for example by issuing country, with the routing log shown afterwards.
2. A soft decline at the first provider that cascades to the second, and a hard decline that does not.
3. An asynchronous local method, such as a voucher or bank transfer, from creation to final webhook.
4. A partial refund, then a full refund of the remainder, with the webhooks for each.
5. A payout that times out and is retried with the same idempotency key, without a duplicate.
6. The same webhook delivered twice, and a late status arriving after a final one.
7. An export of the day’s transactions in the format your finance team would use.

Score what you see against the written answers. Gaps between the two are the most useful finding of the whole process.

How do you score the answers?

Weight the questions before the answers arrive, so the scores are not shaped by the most persuasive response. A simple scheme:

Area	Weight	Scored on
Coverage of your markets and methods	25%	Live connectors for your list, operations supported
Routing, cascading and logs	15%	Demonstrated on test transactions
Tokens and portability	15%	Vault ownership, export terms
Data, webhooks and reconciliation	10%	Sample payloads and reports
Security and compliance	10%	Evidence, not statements
Operations and service levels	10%	Contracted targets and remedies
Pricing over three years	10%	Modelled on your volumes
Exit terms	5%	Written, specific, time-bound

Weights are an example; adjust them to your priorities.

What are the common mistakes?

• Counting connectors. A list of hundreds means little if your three providers in one market are not live.
• Accepting descriptions instead of demonstrations. Routing, cascading, webhooks and refunds should be shown on test transactions.
• Leaving card portability to the end. It is the hardest term to change after signing.
• Ignoring the people. Ask who will run your integration and how support works in your time zones.

How does Omno answer these questions?

Omno is a payment orchestration platform with one API for Pay-In and Pay-Out, routing and PSP-eligibility rules, cascading, tokenization that works across the providers you route to, a hosted checkout, webhooks as the source of truth, reporting and a routing-decision log for every payment. We would rather answer the 30 questions above for your traffic than in general, so send us your list through the contact page, and see the payment orchestration page for an overview.