iGaming Payment Orchestration RFP: Template + Guide

This is the RFP template we’d run for a payment orchestration evaluation in 2026. Use it as a starting point — not every section will apply to every operator, and some will need to be expanded for jurisdictional specifics. The structure is what matters: scope, technical, operational, commercial, and contract, scored separately.

When to run an RFP at all

RFPs aren’t free. They cost the operator team 100-200 hours of senior time and the vendor team a similar amount. They’re worth it when:

• The contract value is six-figures+ annual
• The vendor relationship will last 3+ years
• Multiple internal stakeholders need a say (typical for orchestration: payment ops, engineering, finance, compliance)
• There’s no clear default vendor that everyone already trusts

For smaller decisions or when there’s high pre-existing alignment, a structured shortlist + reference calls beats an RFP for speed and quality of decision.

The template

Section 1 — About us (1 page)

Keep this short. Vendors don’t need a 20-page company history; they need enough context to write a useful response.

• License jurisdictions held
• Approximate monthly deposit volume (a range is fine if you’re cagey)
• Number of brands / verticals operated
• Geographies served, ranked by volume
• Current PSP / orchestration setup
• Reason for the RFP (what’s prompting the evaluation)

Section 2 — Scope (1-2 pages)

This is the section vendors most often respond to with marketing language because operators describe scope vaguely. Be specific.

• Volumes you expect the orchestrator to handle in year 1, 2, and 3
• Payment methods in scope (be exhaustive — list cards, APMs by region, wallets, crypto)
• Geographies in scope at go-live and within 12 months
• Brands / cashier integrations the orchestrator must serve
• Migration scope — replacing a current orchestrator, supplementing one, or greenfield
• Out-of-scope items (e.g. KYC vendor management, fraud-tool selection)

Section 3 — Technical requirements (3-5 pages)

The core of the RFP. Each item gets a Yes / Conditional / No answer plus a 2-3 sentence supporting note from the vendor.

• Integration model (REST API only, SDK, web component, hybrid)
• Authentication mechanism (OAuth 2.0, API key, mTLS)
• Sandbox environment and test-card behaviour
• Webhook event coverage (deposit success, deposit fail, refund, withdrawal, KYC step-up, etc.)
• Smart-routing engine (rule types supported, real-time vs scheduled rule changes)
• Failover handling (automatic, manual, hybrid)
• Retry logic (configurable per route, per method, per error code)
• 3DS handling (per-transaction enforcement, exemption application, frictionless flow %)
• Currency support (FX engine, supported currencies, FX-rate refresh frequency)
• Latency (median p95 p99 for the auth call)
• Uptime SLA over the past 12 months — month-by-month, not aggregate
• Data residency (where transaction data is stored)
• Operator-side reporting (real-time dashboard, batch export, BI integration)
• Tokenisation (token portability — can tokens be exported to a competing orchestrator?)
• Multi-region failover architecture
• API versioning policy and deprecation timelines

Section 4 — Operational requirements (1-2 pages)

What does it look like to run on the vendor’s product day-to-day?

• Named technical account manager and their tenure with the vendor
• Incident escalation paths (P0, P1, P2 — defined by the vendor with sample SLAs)
• Status page and post-incident reporting culture
• Quarterly business review structure
• Roadmap input mechanisms — operator’s ability to influence the roadmap
• New-PSP-add cycle: median time from operator request to live, with examples
• Operator-side configurability without vendor involvement
• Documentation freshness (how often is it updated, sample changelog over the past 6 months)

Section 5 — Compliance and risk (1-2 pages)

• PCI DSS Level 1 — current compliance, attestation date
• SOC 2 Type II — date of latest report, willingness to share
• GDPR posture — DPO, data-processing agreement, sub-processor list
• Insurance — cyber liability policy details
• Penetration testing cadence and willingness to share results
• Vulnerability disclosure programme
• Regulatory-change handling (UK affordability, EU AMLD updates, jurisdictional licence changes)
• Key-person risk — what happens if the vendor’s founder/CTO leaves
• Financial stability — last funding round, runway disclosure (where available)

Section 6 — Commercials (1 page)

Don’t mix this with the technical scoring.

• Pricing model (per-transaction, % of volume, fixed monthly, hybrid)
• Volume tier breakpoints — at minimum 3 tiers
• Implementation fee — should be zero or refundable on launch
• FX spread (if vendor handles FX)
• Chargeback fees
• Termination clause and notice period
• Auto-renewal terms
• Liability cap structure
• MFN clause
• Payment terms (net 30, net 60)

Section 7 — References (1 page)

Ask for three references, with these criteria:

• Two operators within ±50% of your monthly volume
• One operator who switched from a competing orchestrator (so they have a comparison view)
• All three with the vendor for at least 18 months
• Permission to ask reference customers anything except commercial terms

Section 8 — Project plan (1 page)

How would the vendor approach the integration?

• Discovery phase (what they need from you, what they’ll deliver)
• Integration timeline with milestones
• Testing approach
• Go-live ramp (10% / 50% / 100% traffic typical)
• 30 / 60 / 90-day post-go-live success criteria

Scoring framework

Each section gets a separate scorecard with weights. Suggested weights for an iGaming orchestration evaluation:

• Technical fit: 35%
• Operational fit: 25%
• Compliance and risk: 15%
• Commercials: 15%
• References: 10%

Each section scored 1-5 by individual evaluators, then averaged. Don’t blend across sections — keep them separate so you can see the trade-offs.

A vendor scoring 4.5 on technical and 2.0 on operational is a different kind of risk than a vendor scoring 3.5 on both. The blended-average view hides that.

Common RFP failure modes

After helping operators run several of these, the patterns of bad RFPs:

• The 30-page open-ended question dump. Vendors respond with marketing copy because the questions invite it. Be specific, be Yes/No-answerable, and limit page count.
• No scoring rubric. Without a rubric, scoring is political. Each evaluator brings their own bias and the highest-status voice wins.
• Mixing technical and commercial scoring. A vendor with aggressive pricing crowds out the deeper questions about fit.
• Including the incumbent vendor without honesty about the situation. The incumbent will respond as if they have a chance; if they don’t, you’ve wasted everyone’s time including theirs.
• Optimising for the response, not the relationship. The vendor that writes the best RFP response is not always the vendor you want to work with for 3 years. Reference calls + technical demos catch this.
• Neglecting termination terms. Operators sign 3-year contracts with 6-month notice and discover at year 2 that they’re stuck with a vendor that’s no longer the right fit. Always negotiate notice down.

Where Fluid fits in this picture

Fluid sits in the cashier-UX-layer category, not the orchestration category — but we work with every major orchestrator. If you’re running an orchestration RFP, we’re typically not on the longlist (we’re not the right product). If you’re running a cashier RFP, we usually are. See iGaming Payment Solutions Comparison for the distinction, and our iGaming Payment Provider Evaluation Checklist for the cashier-side equivalent of this template.

If you’d like to brainstorm an RFP draft with someone who’s been on the operator side of these conversations, we’re happy to help — no expectation of a Fluid pitch attached.