Choosing a payment orchestration platform isn't like choosing most software. Every payment you take will pass through it, the integration is hard to unwind, and its failures are your customers' failed payments. Yet evaluations often run on feature grids that every vendor can tick, because the hard questions are in the details: what happens on a timeout, who holds the provider contracts, how a success rate is defined, how you leave.
This is a vendor-neutral list of questions for a request for proposal, grouped by area, with notes on what a strong answer looks like. We publish it as an orchestration platform ourselves; use it on us as well as anyone else. Our guide to payment orchestration architecture describes the components these questions probe.
Before you write the RFP
Vendors answer the questions you ask. Write down your own situation first, so answers can be judged against it:
- Payment methods and markets you need now and within two years, and the share of volume each carries.
- Providers you already use, and whether you want to keep those contracts.
- Recurring payments, saved cards and mandates, and payouts or refunds at volume, which constrain routing and migration.
- Peak volume and the moments it happens.
- What's hurting today: outages, cost, success rate, reconciliation effort, engineering time. Your evaluation should measure these.
1. Providers, coverage and contracts
Coverage claims are easy; connected, live, maintained connectors are what matter.
- Which providers and payment methods are live today, in which markets? Which are on a roadmap, and with what dates?
- Who holds the contract with each provider: you, or the platform? Can you bring your own provider agreements and pricing?
- Who runs merchant onboarding and checks with each provider, and how long does adding a provider take in practice?
- When a provider changes its API, who updates the connector, and how quickly?
A strong answer distinguishes clearly between what's live and what's planned, and is specific about contracts. Ambiguity about who signs with providers will matter later, at renewal, during disputes and when you leave.
2. Routing
Every platform routes. Ask how decisions are made and whether you can see them:
- What filters run before ranking (method, currency, amount, token or mandate ownership, provider health)?
- What rules can you set yourselves, and what signals rank providers: success rate, latency, cost? Over what time window, and at what level of detail (provider and method, bank, card network)?
- Is each routing decision stored on the payment, with candidates, exclusions and reasons, and visible to your support team and through the API?
- Can you override routing per request, and split traffic by percentage to trial a provider?
3. Retries, failover and the unknown
This is where platforms differ most, and where weak answers cost the most:
- How are failures classified, and which categories are retried?
- What happens when a provider times out? Is the payment's status checked before any retry?
- Are retries under the same idempotency key and reference, so the business sees one payment?
- How is a late success on the first provider, after a retry succeeded elsewhere, detected and handled?
- How is provider health measured, when is a provider paused, and how is traffic restored?
If a vendor says it retries every failure on another provider, ask how it avoids charging customers twice. Our guides to duplicate payments and payment API timeouts explain what to listen for.
4. API, webhooks and developer experience
Read the documentation before the demo. Then ask:
- What are the payment statuses and the error model? Is there a retryable flag and a decline category?
- Are idempotency keys supported on every money-moving request, and for how long are they kept?
- Are provider references (RRN, UTR, provider IDs) and your own reference and metadata kept on every payment, event and report?
- How are webhooks signed, retried and ordered? Is ordering guaranteed? (It usually isn't; a candid answer is a good sign.)
- What is the versioning and deprecation policy? Our guide to payment API versioning explains what a good one looks like.
- Does the sandbox simulate failures, timeouts, refunds and webhooks, not just successful payments?
5. Security, compliance and regulation
Ask for evidence, not adjectives:
- What is the platform's PCI DSS validation, and can you see the Attestation of Compliance? Where is card data held, if anywhere, and how does integrating affect your own PCI scope? Our guide to PCI DSS SAQ types explains scope.
- In India: what is the platform's regulatory role? Is it an RBI-authorised payment aggregator that handles funds, or a technology service provider that doesn't? Who holds your money between payment and settlement? Our guides to the RBI payment aggregator directions and technology service providers explain the difference.
- Where is payment data stored and processed? For Indian payments, RBI's 2018 direction on storage of payment system data applies.
- Which certifications and audits can be verified independently, and how recent are they?
- How quickly will you be told about a security incident affecting your data?
6. Reliability
An orchestration layer removes single points of failure among providers, but can become one itself. Ask directly:
- How is the platform made redundant, and what happens to your payments if the platform itself is unavailable?
- What uptime is committed in the contract, how is it measured, what is excluded, and what is the remedy if it's missed?
- Is there a public status page and incident history? Ask for the last few incident reviews.
- What are the recovery objectives for data and service after a major failure?
7. Reconciliation, reporting and data
The money only counts once it's reconciled:
- Are every provider's settlement reports ingested, whatever their format, and matched to payments, refunds and fees?
- Are fees checked against your agreed rates, with GST itemised?
- What exceptions does reconciliation report, and how are they worked?
- Can you export raw payment and settlement data, by API and file, without limits on history?
- How is success rate defined in dashboards? Our guide to payment success rate explains why the definition matters.
8. Pricing and the cost you'll actually pay
Make vendors price your volume, not a brochure tier:
- What are the platform fees and transaction fees, and are provider costs passed through separately?
- Are there minimums, overage charges, or fees for adding providers, methods or markets?
- Are failed attempts and retries charged, by the platform or by providers?
- Is GST included or extra?
Build a cost model with your own volumes and method mix for each vendor, including provider costs, and compare effective cost per successful payment. Our guide to payment gateway charges explains how to read pricing sheets.
9. Exit
Ask about leaving before you join. It's the question vendors least expect and the one you'll be gladdest you asked:
- What notice period applies, and what happens to your data when you leave? In what format can it be exported?
- Can saved cards, tokens and mandates move with you, or will customers need to re-authorise? (Often they will; it depends on who holds them.)
- If you hold the provider contracts, can you connect to those providers directly on day one after leaving?
Our guide to switching payment gateways describes what a migration involves, which is useful context for this conversation.
Test the answers
A written answer is a claim. Before deciding, turn the most important ones into tests:
- Run your own scenarios in the sandbox: a timeout, a duplicate webhook, an out-of-order event, a decline followed by a retry, a refund, a partial refund.
- Ask for a routing decision record and a reconciliation exception report from the sandbox or a demo account.
- Speak to two reference customers with a profile like yours, and ask what went wrong and how it was handled.
- Ask your security team to review the Attestation of Compliance and any audit reports.
- Put the answers you rely on into the contract, especially uptime, data export and exit terms.
Red flags
Answers that should prompt a closer look:
- "We retry every failed payment on another provider" with no mention of status checks or idempotency.
- Success rates quoted without a definition, or improvements promised as a percentage before seeing your data.
- Vague answers about who signs with providers or who holds funds.
- Certifications or partnerships that can't be verified.
- No sandbox, or a sandbox that only returns success.
- No straight answer about exit and data export.
If you'd like to put these questions to LILPE, our why LILPE page and comparisons set out where we fit, our pricing page explains how fees are structured, and you can contact us for a proposal against your own volumes.
Frequently asked questions
What should a payment orchestration RFP include?
Your own requirements (methods, markets, volumes, providers, recurring and payouts), then questions on provider coverage and contracts, routing, retries and failover, API and webhooks, security and regulatory status, reliability, reconciliation and reporting, pricing, and exit terms, with a plan to test the key answers in a sandbox.
How do I compare payment orchestration platforms?
Score them against your own priorities rather than a generic feature list, model the cost at your volumes and method mix including provider costs, test failure scenarios in each sandbox, and speak to reference customers similar to you.
Is a payment orchestration platform a single point of failure?
It can be, which is why reliability questions matter: how the platform is made redundant, what uptime it commits to in the contract, its incident history, and what happens to your payments if it's unavailable.
Can I keep my existing payment gateway contracts with an orchestration platform?
Some platforms let you connect your own provider agreements; others contract with providers themselves. Ask directly, because it affects your pricing, your relationship with each provider and how easily you can leave.
Official sources
- RBI — Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 (15 Sep 2025)
- RBI — Storage of Payment System Data (6 Apr 2018)
- PCI Security Standards Council — PCI DSS
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
