01
Payment gateway
The gateway commonly supplies checkout or API connectivity, securely transmits payment data and routes technical messages. It may not underwrite the merchant or settle funds.
Payment infrastructure roles
Payment gateway vs PSP vs acquirer: know who does what.
Payment companies often combine several roles under one brand, which makes provider comparisons confusing. The useful question is not the label alone, but who supplies connectivity, underwriting, regulated payment services, settlement and operational support for the merchant’s route.
Send a private payment brief
Practical guidance
The roles behind a payment route
One company may perform several roles, while another route may combine multiple specialists under separate contracts.
02
Payment service provider
A PSP packages payment acceptance or related services for merchants and may combine gateway, acquiring access, local methods, risk tools, reporting and support.
03
Acquirer
The acquirer contracts for card acceptance, underwrites the merchant for that acquiring relationship and participates in clearing and settlement under card-scheme rules.
04
Processor and orchestration layer
A processor handles transaction messages and records; an orchestration platform may connect several providers, route transactions and centralise integration without replacing provider approval.
05
Alternative payment provider
Open Banking, A2A, wallets, vouchers and payout specialists may support non-card flows with their own eligibility, settlement and integration model.
06
Merchant responsibilities
The merchant still owns accurate onboarding information, lawful market access, customer terms, operational controls, reconciliation and compliance with its provider agreements.
Decision checkpoints
Questions to ask before choosing the stack
Resolve contractual and operating responsibility before comparing interface features or headline coverage.
D1
Who underwrites the merchant?
Identify the entity making the compliance and risk decision and whether separate approval is required for each route or method.
D2
Who holds and settles funds?
Document the regulated party, settlement account, currencies, timing, reserves and what happens to funds during refunds or disputes.
D3
Who owns the integration?
Confirm APIs, tokens, webhooks, reporting, support boundaries and whether the merchant can migrate or add a backup provider.
D4
Who handles incidents?
Set escalation paths for failed payments, delayed settlements, reconciliation gaps, fraud events and provider-side changes.
Practical detail
Map every payment role to a contract and an owner
Labels are not enough because one company can perform several roles and one payment route can combine several companies. A usable architecture records who contracts with the merchant, who makes the risk decision, who handles transaction data, who controls settlement and who responds when the route fails.
| Architecture question | Evidence to prepare | Failure caused by leaving it unclear |
|---|---|---|
| Who approves the merchant? | Contracting entities, regulated roles, onboarding forms, required documents and the party issuing the final approval or decline. | The project treats a technical gateway integration as proof that an acquirer or payment provider has approved the merchant. |
| Who routes the transaction? | Checkout, gateway, processor and orchestration diagram with tokens, authentication, webhooks, routing rules and retry ownership. | Two suppliers both assume the other owns authentication, token portability, retries or incident investigation. |
| Who moves and settles funds? | Acquiring or payment-rail contract, settlement account, currencies, timing, reserves, fees, refunds and dispute funding. | The commercial proposal does not identify the regulated funds-flow owner or the merchant cannot reconcile net settlement. |
| Who operates the route? | Support boundaries, monitoring, reconciliation, incident severity, escalation contacts, change control and backup procedure. | A live failure has no accountable owner, or the fallback route depends on tokens and data that cannot be moved. |
Brief example
Example payment-stack responsibility matrix
A practical brief can use one row per component: checkout, gateway, orchestration, processor, acquirer, alternative method and payout rail. Each row names the contracting party, regulated role, data handled, underwriting owner, settlement responsibility, currencies, reports, support boundary and exit dependency. This makes overlapping claims visible before contracts and integration work begin, without publishing provider identities or private commercial terms.
B1
Contract map
Legal entity on each agreement, service description, regulated responsibility, approval dependency and termination or migration condition.
B2
Data map
Checkout fields, card or account data, tokens, authentication, routing, webhooks, reporting and access-control ownership.
B3
Funds-flow map
Customer authorisation, clearing, settlement, reserves, refunds, disputes, payout and reconciliation from gross to net.
B4
Operations map
Monitoring, support hours, incident owner, escalation, change notices, backup route, reporting and finance responsibilities.
Glossary
Payment-stack glossary
- Gateway
- The technical layer that captures or transmits payment instructions; it does not necessarily underwrite or settle for the merchant.
- PSP
- A payment service provider that may bundle access to methods, acquiring, gateway, reporting, risk tools and support.
- Acquirer
- The entity providing the merchant's card-acquiring relationship and participating in card clearing and settlement.
- Processor
- The infrastructure handling transaction messages and records between payment participants.
- Orchestration
- A control layer connecting multiple payment routes and applying routing or failover logic without replacing provider approval.
Review process
Where payment-stack decisions go wrong
OfferPSP can check a responsibility matrix in 1–2 business days and use approximately 3–10 business days as a planning range for initial discussions with relevant providers after the merchant profile is complete. Underwriting, contracting, data review and integration usually take several additional weeks. These are planning estimates, not a provider SLA or a promise that a route will be approved.
Common brief mistakes
- A signed gateway or orchestration agreement is mistaken for merchant approval by an acquirer.
- The proposal does not name the regulated entity that holds or settles funds and owns reserves or disputes.
- Token ownership, reporting, reconciliation, incident response and migration dependencies are left outside the contract map.
What speeds up the provider decision
- Build one matrix linking every supplier to its contract, regulated role, data, funds and support responsibility.
- Trace an authorisation, refund, dispute and settlement through the full stack before selecting architecture.
- Test the backup and exit path on paper, including token portability, reconciliation and operational ownership.
Decision checklist
Map the provider roles
Specific, current information improves the quality of every provider conversation.
Contracting and regulated entities
Merchant underwriting owner
Gateway and API operator
Acquirer or payment rail
Settlement and reserve owner
Risk, fraud and dispute tools
Reporting and reconciliation
Support and incident escalation
Questions
What businesses usually ask
Is a PSP the same as a payment gateway?
A PSP is not necessarily the same as a payment gateway. A gateway commonly provides technical connectivity, while a PSP may bundle connectivity with payment services, underwriting access, reporting and support.
Is a PSP always an acquirer?
A PSP is not always an acquirer. Some PSPs acquire directly, while others connect merchants to one or more acquiring or payment partners; the contract and funds flow identify the actual roles.
Can a merchant use a gateway with several PSPs?
A merchant can use one gateway with several PSPs when the gateway or orchestration layer supports the providers, token and data model, routing logic and operational reconciliation required.
Who decides whether a merchant is approved?
The provider or acquiring entity responsible for the route makes the compliance and underwriting decision. A gateway or intermediary cannot guarantee that approval.
How does OfferPSP help choose between these models?
We structure the entity, GEO, method, currency, flow, integration and settlement requirements, then assess which provider roles and routes are relevant for a controlled introduction.
Continue with the service
Related guides and matching briefs
Use the guide
Turn the checklist into a provider-ready payment brief.
Share the company, target GEOs, vertical, methods, volume and current constraint. We will assess the next useful step without publishing your provider search.