Gambling Payment Gateway Integration Services: Operator RFP and Acceptance Tests

For iGaming operators, a payment-gateway integration is not finished when a test card succeeds. It is finished when the cashier, payment service provider (PSP), player-account system, wallet ledger, risk workflow and finance records agree through failures, retries, refunds and withdrawals. This guide is an operator-side brief for selecting an integration partner and accepting the work—not a directory of untested service providers or a claim that NowG sells gateway integration.

Use it when an operator is adding a PSP, replacing a gateway, expanding into a new regulated market, or repairing a fragile cashier. The contract should name the owners of the integration boundaries and define the evidence required for sign-off. Payment methods, regulatory duties and data flows vary by jurisdiction and licence; counsel, the acquirer and qualified payment-security advisers should review the applicable requirements.

What the integration partner is actually responsible for

“Gateway integration” can mean very different scopes. One firm may only connect a hosted checkout. Another may own PSP routing, tokenization, pay-in and payout orchestration, reconciliation, monitoring and a migration. Ask bidders to mark every component as build, configure, test, operate or out of scope.

Boundary	Operator question	Acceptance evidence
Cashier and payment page	Who controls the player experience, amount, currency, method display and failure message?	Recorded desktop/mobile test journeys by market
PSP API and authentication	Who owns credentials, request signing, idempotency and version changes?	Architecture, key-handling plan and retry test
Wallet/PAM	Which event makes funds available, and how is a failed or reversed payment handled?	Ledger entries matched to PSP references
Risk and identity	Where do KYC, fraud, AML and safer-gambling holds act on the flow?	Case-level test with decision and override log
Payouts and refunds	How are eligibility, approval, beneficiary and status changes controlled?	End-to-end payout and refund test cases
Finance and support	Who reconciles settlement, fees, reserves, chargebacks and exceptions?	Sample daily reconciliation and incident runbook

A useful contract separates the technical integrator from the regulated operator, PSP/acquirer and any platform vendor. The service provider can build and test a control, but the operator still needs to decide its policy, obtain approvals and monitor outcomes.

Send a precise RFP instead of asking for “a payment gateway”

Give each bidder the same anonymized brief. Include the licences and markets in scope, current and expected payment methods, currencies, estimated transaction bands, cashier/PAM architecture, wallet posting rules, payout workflow, fraud/AML dependencies and current incident patterns. Do not send live player or card data at the shortlist stage.

• Coverage: Which payment rails and PSPs are already supported in the named markets? Which require a new certification or commercial agreement? Request evidence and dates, not a generic logo wall.
• Ownership: Which party maintains API adapters, webhooks, credentials, 3-D Secure configuration, token portability, alerting and on-call support?
• Commercials: Separate implementation, recurring support, per-transaction charges, minimums, change requests, data migration and exit assistance. Ask for a written overage schedule.
• Timeline: Request a dependency plan for PSP onboarding, sandbox credentials, compliance review, UAT, staged release and rollback. A build estimate without these dependencies is not a launch date.
• Evidence: Require API documentation, security responsibility matrix, sample reconciliation file, incident SLA and named acceptance-test results.

If a supplier promises an approval-rate lift, ask for the baseline definition, geography, payment-method mix, decline-code segmentation and experiment design. A different mix of methods or issuers can change the rate even when the integration has not improved.

The payment state machine an operator should demand

Write the allowed transitions before coding. A practical pay-in model distinguishes initiated, authentication required, authorized, captured/confirmed, failed, cancelled, reversed, refunded and disputed. Not every PSP uses these names or sends every event. The operator must map the PSP’s actual statuses to wallet and support actions and record the original reference.

For a timed-out request, the system should not blindly create a second deposit. Adyen’s API idempotency guidance illustrates why a stable key matters when a payment call is retried. That is vendor-specific documentation, not a promise that all gateways have the same semantics. Ask the bidder to demonstrate the behavior of the chosen PSP, including concurrent requests, key expiry and a missing response.

Likewise, webhooks are not a magical source of truth. Adyen’s webhook guide calls for authenticity checks, safe acknowledgment and duplicate handling. An operator should insist on event storage, signature verification, deduplication and replay testing for its chosen provider. Delivery failures may enter a retry queue, so the integration also needs alerts and a reconciliation path when events arrive late or out of order.

Acceptance tests that expose expensive failures

• Timeout after authorization: The player sees a controlled pending state; a retry does not create a second charge or second wallet credit; staff can reconcile the PSP reference.
• Duplicate and late webhook: Replaying an event does not post the ledger twice; a later status is applied according to documented transition rules.
• Authentication failure: A failed 3-D Secure or redirect journey cannot show a successful deposit or create spendable funds.
• Partial refund and chargeback: The original transaction remains traceable through the adjustment, fee and support case; the ledger is not silently overwritten.
• Withdrawal hold: A risk or identity hold prevents payout initiation, shows a reason to authorized staff and preserves a decision trail without leaking sensitive data to the player.
• Method or PSP outage: The cashier degrades safely, communicates availability and uses only preapproved fallback routes; untested automatic rerouting is not assumed to be legal or supported.
• Day-end reconciliation: Match transaction, PSP settlement, wallet, fees, reserves and bank records; create an exception queue for missing, duplicated or mismatched entries.

Set pass/fail criteria before UAT. Record the test case, environment, software version, PSP reference, expected ledger outcome, actual outcome, owner and fix date. A green dashboard without transaction-level evidence is not sign-off.

Security and compliance: outsourcing does not erase operator duties

Choose the payment-page design with a qualified security adviser. The PCI Security Standards Council’s SAQ eligibility FAQ distinguishes payment pages fully served by validated providers from pages with merchant-origin elements; eligibility depends on all applicable criteria. Its June 2026 FAQ also explains that even some fully outsourced e-commerce merchants retain website-scanning responsibilities. “Hosted checkout” is therefore not a substitute for a responsibility matrix or an assessment.

Licensing obligations also affect the money flow. For example, the UK Gambling Commission’s customer-funds guidance addresses segregation for most remote operators holding customer funds and notes that some funds with a payment processor may be relevant to the segregation assessment. That example should prompt a jurisdiction-specific legal and finance review; it should not be copied as a universal rule.

Score bidders on demonstrable outcomes

Use a simple 0–2 score for each requirement: 0 = no evidence or unsupported; 1 = documented but not demonstrated in your stack; 2 = demonstrated with your test case. Weight the non-negotiable controls—ledger integrity, payment security, market eligibility and operational recovery—more heavily than cosmetic features. Mark unknowns as unknown rather than treating a sales claim as a passed test.

Ask for a short paid or unpaid proof of concept only after PSP access and responsibilities are clear. The POC should prove one complete deposit and one complete payout path, then deliberately break each at a boundary. Keep the evidence, not just a vendor slide deck. The winner is the partner whose integration can be operated, audited and exited safely—not necessarily the one that quotes the fewest build days.

Migration and exit questions often missed

• Can tokens or payment instruments move, and under what permissions and PCI scope?
• Who can export the transaction and settlement history in a usable format?
• How will in-flight deposits, withdrawals, refunds and disputes be reconciled during cutover?
• Can the operator run old and new routes in parallel with clear transaction ownership?
• What triggers rollback, who makes the call and how is player communication handled?
• What support continues after contract termination, including dispute evidence and audit access?

Frequently asked questions

Is a payment gateway the same as a payment processor? No. “Gateway,” PSP, processor and acquirer describe different roles, although one vendor may bundle several. Map the actual contracting, technical and settlement parties for your chosen flow rather than relying on the sales label.

Should we integrate multiple PSPs from day one? Only if the markets, volumes, resilience needs and operational capacity justify it. Multiple routes add reconciliation, reporting and failover complexity. A documented single-PSP architecture with tested recovery may be safer than untested “smart routing.”

What is the first technical question for a bidder? Ask them to draw the exact deposit and payout event sequence and identify which system is authoritative at each step. Then ask what happens when the response or webhook never arrives.

Method note: This is a procurement and UAT framework, not legal, PCI or vendor certification advice. Sources were checked on 17 September 2026. Recheck PSP documentation and market-specific rules before signing or deploying.