The Direct Answer: Treat the RFP as an Operating Contract
A payment orchestration RFP should define how a business will accept, route, retry, reconcile, and report on payments across processors, payment methods, regions, and currencies. It is not simply a request for gateway features; a useful document tests the commercial model, technical design, risk controls, implementation plan, and exit options that will govern the relationship after signature. As of 25 September 2026, buyers should assume that “orchestration” may cover smart routing, tokenization, retries, cascading transactions, payment method management, and unified reporting, but vendors rarely use the term consistently. A strong RFP therefore requires vendors to describe the exact functions they provide and separately identify functions performed by the customer, its bank, or an external processor. Responses should be compared using test scenarios and total operating cost rather than broad product claims or a checklist of feature checkmarks.
Also worth reading: What Is Merchant Payment Orchestration and When Is It Worth the Cost? · How Do You Evaluate Payment Orchestration Platforms Before Switching in 2026? · How Can a Business Migrate to Payment Orchestration Without Disrupting Checkout in 2026?
The RFP should ask for measurable service levels, demonstrable integration patterns, and evidence from deployments resembling the buyer’s business. For example, a retailer processing card-not-present transactions needs different evidence from a marketplace splitting funds among sellers or a subscription business retrying failed recurring payments. A mature response should state the expected authorization rate, fraud rate, latency, availability, reconciliation accuracy, implementation duration, and support response times, while also explaining how those figures are measured. If a vendor promises a 3% authorization-rate lift without naming the baseline, market, period, and causal method, the claim should be treated as marketing rather than a dependable forecast. The best RFP gives shortlisted vendors the same hypothetical data and requires written answers that can later become contractual requirements.
Define Scope, Payment Flows, and Ownership Boundaries
The first substantive section should describe the business rather than merely list desired features. Buyers should identify annual transaction volume, average ticket value, current processing costs, card-on-file usage, mobile share, cross-border exposure, settlement currencies, expected growth, and the number of countries involved. Quantifying existing economics makes responses comparable: a provider offering a 1.5% platform fee may appear inexpensive at $10 million in annual volume but expensive at $100 million if competitors use basis-point pricing. The RFP should also distinguish volume from end-to-end payment value because interchange, processor markups, scheme fees, gateway fees, FX spreads, refunds, chargebacks, and platform charges are calculated on different bases.
Every material flow needs an explicit owner. A typical card purchase can involve a checkout application, orchestration layer, processor, acquiring bank, card network, fraud service, token service, and merchant bank, but one vendor may perform only the routing layer. The document should identify who controls customer data, who stores card credentials, who handles PCI DSS responsibility, who initiates settlement, and who produces the final ledger entry. It should cover direct card processing, wallets, bank debits, account-to-account payments, vouchers, buy-now-pay-later, local payment methods, refunds, partial refunds, voids, recurring payments, disputes, multi-capture, split payments, and payouts where applicable. Unsupported methods should be labeled as such instead of being hidden behind broad references to “alternative payments.”
Require Demonstrable Routing and Retry Behavior
Routing is the clearest reason to buy an orchestration service, but the word does not guarantee intelligent behavior. The RFP should ask vendors to explain default routing, issuer-based rules, geography, currency, amount, payment method, cost, latency, conversion, and historical-performance rules. It should also require examples showing how a transaction moves when the first processor declines or times out, whether failover occurs automatically, and which events can safely be retried. Vendors must distinguish a network timeout from an issuer decline because repeating a payment after an uncertain response can create duplicate charges. Their answer should state the idempotency mechanism, timeout period, retry limits, authorization windows, and reconciliation process.
A useful performance test gives each finalist the same set of transaction profiles and asks it to predict routing outcomes. Useful profiles might include 40% of transactions coming from mobile devices, 15 international currencies, an average ticket of $85, a 95% authorization rate at entry, and a seasonal 60% increase in Black Friday traffic. The response should explain whether routing is learned from the buyer’s own history, shared anonymously across clients, configured manually, or supplied by the processor. Buyers should ask for at least 6-12 months of aggregate results from comparable deployments, where legally permissible, and request permission to validate references. A claimed 4-8% authorization improvement is not automatically attractive if it depends on prohibited data practices, aggressive retrying, or declines merely being moved between processors.
| Evaluation area | Processor-led orchestration | Independent orchestration layer | Manual provider configuration |
|---|---|---|---|
| Typical control | Rules mainly follow the acquirer’s capabilities | Cross-processor rules and routing data in one layer | Rules maintained separately by each provider |
| Multi-acquirer failover | Possible but often constrained by contract or credentials | Usually designed for processor substitution | Requires engineering and operational work |
| Reporting | Processor-specific unless centrally normalized | Central event and cost reporting | Reconciled from provider exports |
| Switching effort | Medium to high | Medium if routing interfaces are standardized | High for every connected provider |
| Best fit | Businesses primarily using one acquirer | Teams seeking active routing and centralized control | Small or low-complexity operations |
| Pricing pattern | Often bundled into transaction or platform fees | Usually platform fee, transaction fee, or usage tier | Included in processor pricing, with internal labor cost |
The integration section should demand documented APIs, stable versioning rules, sandbox access, sample code, webhook semantics, test cases, and a named implementation team. Buyers must determine whether a vendor offers REST APIs only through an aggregator, requires an SDK, or requires a proprietary hosted checkout page. Server-side, mobile, batch, and recurring integrations should be evaluated separately, because strength in one channel does not prove strength in another. The RFP should ask for time estimates to receive production credentials, complete PCI validation, map merchants or entities, configure currencies, connect accounting systems, and launch in a sandbox. A written 12-16 week implementation may be plausible for a standard single-country setup, while a regulated multi-entity rollout can take six months or longer.
Security and privacy questions need specific evidence, not only references to compliance. The response should name applicable PCI DSS and local privacy obligations, describe encryption and tokenization, identify data processors and subprocessors, define retention periods, and explain how credentials are revoked during offboarding. Token portability matters because a token created by one provider may not work with another. Buyers should ask whether tokens are network tokens, processor tokens, or portable vault tokens; which party holds the token-to-card-number mapping; and whether existing credentials can move without exposing primary account numbers. It is also useful to request penetration-test summaries, business-continuity exercises, incident-response targets, and the date of the latest independent assessment. A vendor that cannot provide a PCI responsibility matrix or subprocessor list has not provided enough information for a procurement decision.
Make Pricing, Service Levels, and Support Contractual
Pricing should be normalized into a three-year total-cost model whenever the expected contract is at least that long. The model must include platform access, per-transaction charges, percentage markups, minimum monthly fees, implementation fees, sandbox or testing fees, premium support, chargeback tools, reconciliation exports, API calls, dashboards, FX-related charges, and the cost of the underlying processors. Vendors should state whether refund fees are refunded, whether disputed transactions count toward monthly minimums, how multiple captures are billed, and whether retry attempts count as separate billable transactions. A hypothetical $1 million monthly merchant should be used to test the assumptions, but actual contracted rates and volume tiers should determine the comparison.
Service-level language must be precise. “High availability” has little decision value if the contract does not define a number, measurement window, exclusions, credits, and reporting. The RFP can ask bidders to propose at least 99.9% API availability, a 99.95% authorization service, p95 response times below 500 milliseconds, and critical-production support response within 15-30 minutes, but buyers should adjust those targets to the workflow. Payment authorization availability is not the same as dashboard availability or settlement-processing availability. Proposed credits should compensate for missed obligations, although service credits rarely replace a functioning exit plan. Pricing reviews should occur annually, and fees should be capped or indexed transparently rather than changing through undefined “market rates.”
Compare Alternatives Without Comparing Unlike Products
Payment orchestration should be compared with at least three alternatives: remaining with one integrated acquirer, connecting several processors directly, or using an independent layer with established bank relationships. One integrated acquirer may offer lower operational complexity and useful bundled tools, especially for a small business with one currency, modest volume, and limited engineering capacity. Its weakness is reduced negotiating leverage and less ability to substitute providers, particularly if authorization quality, risk appetite, or geographic coverage is unsatisfactory. A multi-processor direct model can provide control, but it shifts integration, monitoring, credential management, reconciliation, and incident response to internal teams.
An independent orchestration layer can reduce that operating burden and make comparisons easier, but it may add another vendor dependency and an extra fee. The decisive question is whether the expected authorization gain, lower processing cost, reduced engineering work, or improved resilience exceeds the additional expense and migration effort. For a business processing $20 million annually, a 10-basis-point improvement equals $20,000 before considering other fees or adverse effects. At $1 billion, the same nominal improvement equals $1 million, making detailed sensitivity analysis worthwhile. Comparisons should use the same transaction mix, currency, risk settings, fees, refund profile, and calculation period; otherwise, the apparent winner may simply process a safer portfolio.
Independent white-label platforms can also be alternatives when a software company needs to embed branded payment experiences in its own product. The buyer should not assume a white-label gateway owns acquiring, banking, or settlement; these responsibilities may sit elsewhere. As a category, 2026 white-label platform reviews can help identify candidate architectures, but the sponsoring publication, product relationships, evidence quality, and update date should be examined. Claims should be verified through direct demonstrations, contract documents, reference calls, processor confirmations, security review, and a limited production pilot. Marketing rankings are discovery aids, not substitutes for due diligence.
Anticipate Common RFP and Implementation Mistakes
A frequent mistake is asking about “best-in-class support” without defining severity, channels, hours, response time, and escalation rights. Another is requesting every payment method from every vendor even though local methods require local bank access, merchant eligibility, settlement rules, and reconciliation. Buyers also underestimate implementation by writing launch as a single event instead of separating discovery, integration, certification, user acceptance testing, security approval, processor certification, staged rollout, and full production launch. A checkpoint after 5%, 25%, 50%, and 100% of volume provides more control than moving directly from a clean sandbox to national scale.
The RFP should also prevent performance claims from being multiplied without safeguards. Authorization improvement can be offset by higher processing fees, lower acceptance on later retries, increased fraud, or a worse customer experience. A vendor may reroute declined transactions while reporting the initial decline as recovered, making the metric look better than the economics. Ask for net authorization rate, cost per successful payment, duplicate-charge rate, fraud basis points, refund rate, and time to settlement together. Establish a holdout or compare equivalent periods where possible, and review the routing model after 30, 60, and 90 days. If the service does not beat the agreed baseline after fees and operational costs, the contract should permit tuning, removal, or termination.
Data portability deserves equal attention. Buyers should obtain transaction exports, event histories, refund and dispute records, reconciliation files, token migration terms, documented deletion procedures, and an assistance period after termination. Contracts should address what happens during insolvency, acquisition, processor withdrawal, regulatory restriction, or a force-majeure event. Multi-provider resilience is not real if credentials cannot be exported and a new acquirer cannot be activated within an agreed period. A 30-day data-export window may be inadequate for a regulated business, while a 90-day transition commitment can still be unrealistic if bank onboarding alone takes eight weeks. Exit timing should therefore be tied to processor and bank lead times, not only the orchestration vendor’s stated support window.
When to Issue the RFP and How to Select the Winner
Issue the RFP when a business has enough complexity to justify orchestration: multiple processors are likely within 24 months, current failures are material, authorization is below target, or engineering effort is becoming a recurring expense. A business with fewer than roughly 5,000 monthly transactions, one currency, and one processor may get better value from negotiating directly with its acquirer. The threshold is not absolute, but below it, platform minimums and implementation costs can consume much of the expected benefit. Growth projections matter more than present volume; a 100% annual increase can justify a 12-16 week evaluation now rather than a rushed migration after problems become visible.
A structured evaluation should give price 20%, routing and performance 25%, integration 15%, security and compliance 20%, service and support 10%, and roadmap or differentiation 10%, for example. These weights can change, but documenting them reduces preference based on presentation style. Require all finalists to answer identical scenarios, provide a complete pricing exhibit, demonstrate the product, and discuss contract terms. Reference calls should include one customer of similar size and one customer using multiple processors. Final selection should be approved by finance, payments operations, engineering, security, legal, and the business owner because no single department can evaluate authorization improvement, token handling, and settlement consequences alone.
A limited pilot is the final filter. Route no more than 5-10% of eligible traffic initially, preserve rollback capability, and compare the pilot against a control group for at least four to eight weeks. Review authorization, realized cost, latency, fraud, refunds, disputes, reconciliation differences, support incidents, and engineering workload. Expansion should occur only when the results meet written thresholds, such as a positive net financial benefit after orchestration fees and no material rise in duplicate payments or fraud. If no platform meets the target, remaining with the current provider and correcting contracts or risk controls may be the rational decision. The RFP’s purpose is not to justify buying orchestration; it is to determine whether orchestration is the safest and most economical way to solve a documented payment problem.