Processors, gateways, and PSPs
Between a merchant's checkout application and the underlying acquiring bank operates an ecosystem of technology providers and financial intermediaries. Terms like "gateway," "processor," "payment service provider," and "acquirer" are frequently used interchangeably in vendor marketing, obscuring the specific legal and technical roles each company fulfills.
Understanding where each provider sits in the processing stack is vital during operational incidents, as it dictates who has the technical capability and regulatory authority to resolve specific issues.
Technical and legal layers
The payments intermediary stack can be categorized by two fundamental criteria: whether the entity takes custody of settlement funds, and whether it holds direct membership in the card schemes:
| Entity type | Primary operational function | Takes custody of funds? | Direct card scheme member? |
|---|---|---|---|
| Gateway | Encrypts and transmits payment credentials from checkout to the processor | No | No |
| Processor | Translates API requests into ISO 8583 banking switch messages for clearing | No | No |
| Payment Service Provider (PSP) | Aggregates multiple merchants under an established acquiring master relationship | Yes (transitory) | No (leverages sponsor bank BIN) |
| Payment Facilitator (PayFac) | Onboards and underwrites sub-merchants under its own master merchant account | Yes | No (sponsored by licensed acquirer) |
| Acquirer | Licensed financial institution that underwrites risk and settles with schemes | Yes | Yes |
A gateway serves strictly as an encryption and routing bridge, securely capturing sensitive payment data and dispatching it to processing endpoints without holding funds. A processor manages the complex message translation, protocol compliance, and batch clearing files that interface with card network switches.
A payment service provider (PSP) packages gateways, processing engines, and acquiring relationships into modern developer APIs. A specialized evolution of the PSP model is the payment facilitator (PayFac). A PayFac establishes a master merchant account with a sponsor acquirer and onboards individual commercial sellers as sub-merchants under its master agreement. This structure allows software platforms and online marketplaces to onboard new sellers in minutes, because the PayFac conducts automated underwriting under its own umbrella rather than requiring each seller to undergo formal bank review.
Incident diagnosis and escalation mapping
When transactions fail or disbursements are withheld, contacting the wrong provider wastes valuable operational time. Trace the symptom to the responsible layer:
| Operational symptom | Primary responsible layer | Remediation action |
|---|---|---|
| Checkout forms fail to render or reject API payloads | Payment gateway or frontend integration | Inspect API error responses, TLS configurations, and client credentials |
| Abnormal authorization decline spikes across multiple cards | Issuing bank decisioning or network routing | Review processor decline code distributions and verify network availability |
| Batch settlement fails to close at expected cut-off | Payment processor | Check processor status dashboards and re-transmit clearing batch files |
| Funds settle to processor but bank disbursement is missing | PSP, PayFac, or acquiring bank | Verify merchant payout schedules, account verifications, and compliance holds |
| Unexpected reserve withholding or sudden funding delay | Acquirer or PayFac risk management | Engage acquiring risk teams regarding volume spikes, refund rates, or dispute ratios |
| Ambiguity regarding scheme rules or dispute timeframes | Card network scheme rules | Consult published network manuals or request clarification from the acquirer |
A fundamental operational rule governs payment incident response: technical message anomalies belong to the entity routing the messages, while missing or delayed balances belong to whichever financial institution holds custody of the funds.
Terms introduced
- Gateway: a message router between the merchant and the processor. It never holds funds.
- Processor: the party running authorization and clearing messages on an acquirer's behalf.
- Payment service provider: an aggregator that places many merchants under one acquiring relationship. Often shortened to PSP.
- Payment facilitator: a PSP that onboards sub-merchants under its own master merchant account. Often shortened to PayFac.
- Sub-merchant: a merchant operating under a facilitator's master account rather than its own.
- Master merchant account: the facilitator's own account, through which its sub-merchants transact.
How providers do it
Payment service providers rarely operate as pure gateways or standalone processors. Most modern fintech vendors package multiple infrastructure layers into a single commercial contract, blurring the boundary between software gateways, payment processors, and acquiring banks.
The key operational question when evaluating providers is which entity holds the actual acquiring license and card network memberships. That institution dictates settlement speed, controls risk reserves, and serves as the ultimate point of escalation when settlement funds fail to arrive.
| Provider | Platform classification | Acquiring bank entity | Status |
|---|---|---|---|
| Stripe | Payment Service Provider (PSP) bundling gateway, processing, and acquiring | Stripe directly, or licensed partner sponsor banks depending on jurisdiction | unconfirmed per country |
| Stripe Connect | Embedded platform monetization layer operating over Stripe infrastructure | Same as Stripe | confirmed |
| Adyen | Full-stack acquirer, processor, and gateway operating on a unified core ledger | Adyen directly, licensed as a credit institution / bank in the EU, UK, and US | confirmed |
| Worldpay Express | Payment gateway and transaction processing engine | Sponsoring acquiring bank behind the gateway, rather than the gateway itself | unconfirmed |
| Payrix | Payment-Facilitator-as-a-Service engine (marketed as Worldpay for Platforms) | Worldpay acquiring infrastructure | unconfirmed |
| Global Payments | Global merchant acquirer and core processor (parent of Worldpay) | Global Payments directly or regional bank partners | unconfirmed |
| Braintree | Gateway and full-stack PSP (division of PayPal) | Braintree acquiring entities, PayPal, or merchant's third-party acquirer | unconfirmed |
| Checkout.com | Unified cloud-based acquirer and processor | Checkout.com directly across jurisdictions where regionally licensed | unconfirmed per region |
| Square | Payment Facilitator (PayFac) aggregating micro and mid-market merchants | Square master acquiring account sponsored by partner banks | confirmed |
| Fiserv | Global payment processor (First Data core platform) | Partner sponsor banks (often unnamed in standard processing agreements) | unconfirmed |
Corporate consolidation in the payments industry frequently obscures provider redundancy. For example, Global Payments acquired Worldpay, and Payrix operates as their embedded platform division. Treating them as three competing bids during vendor selection often yields identical backend terms and settlement routing.
- Stripe
- Stripe Connect
- Adyen
- Worldpay Express
- Payrix
- Global Payments
- Braintree
- Checkout.com
- Square
- Fiserv
What they are: a PSP. Stripe is the gateway, the processor, and the acquiring relationship sold as one product, so there is no separate bank to call.
That collapses the escalation table on this page into one row. Whatever the layer, the ticket goes to Stripe. What it costs is the lever the table implies: a routing problem cannot go to a different processor while the acquiring stays, because the two were never bought separately.
| Question | Answer | Status |
|---|---|---|
| Which bank actually sponsors the merchant? | Varies by country. Stripe holds the acquiring licence in some markets and uses a partner bank in others | unconfirmed; ask per country of sale |
| Is the acquirer BIN a transaction went out under visible? | unconfirmed | |
| Who is above first-line support? | unconfirmed; get a named contact before one is needed |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Merchant ID | Account, acct_… | confirmed |
| Sub-merchant | Connected account, under Connect | confirmed |
Last verified: never.
What they are: the platform layer on top of Stripe, and the reason "who is the merchant" has more than one answer. Connect does not change who processes the payment. It changes whose balance the money lands in, whose name is on the statement, and whose balance a chargeback comes out of.
Three charge types decide all of that, and picking one is an underwriting decision dressed up as an API choice.
| Charge type | Payment lands in | Refunds and chargebacks debit | Status |
|---|---|---|---|
| Direct charge | The connected account's balance | The connected account | confirmed |
| Destination charge | The platform's balance, with a transfer out to the connected account | The platform | confirmed |
| Separate charges and transfers | The platform's balance, transfers sent afterwards | The platform | confirmed |
On destination charges and separate transfers the platform is debited first and recovers from the seller afterwards by reversing the transfer, which only works if the seller still has a balance. That is the funding question this page hands off, and it is the one that bites.
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Sub-merchant | Connected account | confirmed |
| The platform's cut of a sale | application_fee_amount | confirmed |
| Make the seller the business of record | on_behalf_of on the payment | confirmed |
| Act as this sub-merchant | Stripe-Account request header | confirmed |
| Pay a seller out | Transfer, then payout | confirmed |
| Question | Answer | Status |
|---|---|---|
| Which charge type applies, per product line? | unconfirmed; answer before reading anything else here | |
| Who carries loss liability on the connected accounts? | Set per account, through the account's controller configuration | unconfirmed; confirm how they are set |
| Can a transfer be reversed once the seller's balance is empty? | No. The debit sits on the platform | unconfirmed |
Where to look
The platform's Connect dashboard for the account list and its capabilities. On a single
payment, the transfer_data, application_fee_amount and on_behalf_of fields tell you which
model that payment used, whatever the integration was meant to do.
Last verified: 2026-09-09 against Stripe's public Connect documentation.
What they are: gateway, processor, and acquiring bank in one company. Adyen holds banking licences in the EU, the UK and the US, so in those markets there is no separate sponsoring bank sitting behind them.
That answers the question this page says is hard. Ask "who is the acquirer" on an Adyen transaction in a licensed market and the answer is Adyen. Outside those markets they may be routing through a partner acquirer, and then the answer is different, so it is worth asking per country rather than once.
| Question | Answer | Status |
|---|---|---|
| Do they hold the acquiring licence in every country of sale? | Licensed in the EU, the UK and the US | confirmed for those three; unconfirmed elsewhere |
| Where a partner acquirer is used, which one? | unconfirmed | |
| Who does a routing decision escalate to? | unconfirmed |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Merchant ID | Merchant account | confirmed |
| Transaction reference | PSP reference | confirmed |
| Dashboard | Customer Area | confirmed |
| Webhook | Notification, or webhook | confirmed |
Where to look
The Customer Area, per merchant account. Anything that varies by country varies by merchant account too, so read it there rather than assuming one answer covers the estate.
Last verified: 2026-09-09 against Adyen's public documentation.
What they are: a gateway and processing platform, sold mostly through integrated software and card-present estates. Express is one of several Worldpay platforms rather than the whole company, so a Worldpay contract does not tell you which system your transactions run on. Ask for the platform name.
Worldpay was acquired by Global Payments, and the deal closed in January 2026. Payrix is the same group's platform product. Three of the tabs on this page are now one company, which matters when a switch is being priced and it looks like a second supplier.
| Question | Answer | Status |
|---|---|---|
| Which Worldpay platform is in use? | unconfirmed; Express, Access, and the older Vantiv and RBS-era systems are different products | |
| Who holds the acquiring relationship behind Express? | unconfirmed | |
| Has the Global Payments merger changed the support path? | unconfirmed; ask at the next review |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Auth-only | CreditCardAuthorization | confirmed |
| Capture an earlier auth | Completion, against the original TransactionID | confirmed |
| Stored card token | PaymentAccountID | confirmed |
| Hosted checkout session | TransactionSetupID, valid for ten minutes | confirmed |
Where to look
The Express interface specification, which Worldpay publishes as a PDF, is the document that answers most integration questions. It is versioned. Check which version the integration was built against before trusting a field description.
Last verified: 2026-09-09 against Worldpay's published Express interface specification.
What they are: the facilitator layer bought as a service. Payrix, marketed as Worldpay for Platforms, lets a software platform onboard sub-merchants and set their pricing without registering as a payment facilitator itself. Underwriting and the losses stay with Worldpay in that model.
Read that against the facilitator section on this page. The economics of being a PayFac are available without the licence, and what a platform gives up is control of the risk decision. When Payrix declines to onboard a seller, or holds one, the platform cannot overrule it.
| Question | Answer | Status |
|---|---|---|
| Which engagement model applies? | Referral, PayFac-as-a-service, or a registered PayFac model, and they differ in who carries the risk | unconfirmed; the contract names it |
| Who is the merchant of record for a sub-merchant sale? | unconfirmed; this is the funding question, and it decides who the chargeback lands on | |
| Who underwrites a new sub-merchant, and how long does it take? | unconfirmed | |
| Is the decline reason visible when onboarding fails? | unconfirmed |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Sub-merchant | Merchant, onboarded under a partner | confirmed |
| The platform | Partner | confirmed |
| Whoever carries the PayFac risk | Facilitator | confirmed |
| Transaction | txn | unconfirmed |
| Paying a seller out | Disbursement | confirmed |
Last verified: 2026-09-09 against Payrix's public resource centre.
What they are: an acquirer and processor, and since January 2026 also the owner of Worldpay. They sell acquiring, gateway and terminal estates, and they reached that position by acquisition, so the group runs several unrelated platforms.
That is the practical problem with them. "Global Payments" names a company, not a system. The integration you have determines the API, the reports, the support queue and the vocabulary, and two teams inside the same business can be on platforms with nothing in common.
| Platform | What it is | Status |
|---|---|---|
| GP API | The current unified REST API | confirmed |
| Portico | The Heartland gateway, US-focused | confirmed |
| GP-ECOM | The former Realex platform, used in Europe | confirmed |
| Hosted Payment Page | Their hosted checkout, on either ecommerce platform | confirmed |
| Question | Answer | Status |
|---|---|---|
| Which platform is each integration on? | unconfirmed; answer per integration, not per contract | |
| Is the acquiring contracted directly, or through a reseller? | unconfirmed | |
| Which entity issues funding, after the Worldpay merger? | unconfirmed |
Last verified: 2026-09-09 against Global Payments' developer portal and the merger announcement.
What they are: a gateway and PSP owned by PayPal. Braintree processes the card transaction and, on the same integration, accepts PayPal and Venmo as payment methods, which is the reason most merchants are on it.
The acquiring underneath depends on the arrangement. Braintree can sit in front of a merchant's own acquirer or supply the acquiring itself, so this is a contract question rather than a product one.
| Question | Answer | Status |
|---|---|---|
| Is the merchant account behind Braintree the merchant's own, or Braintree's? | unconfirmed | |
| Which acquirer processes the card volume? | unconfirmed | |
| Do PayPal-funded sales settle on the same schedule as card sales? | unconfirmed; expect not |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Merchant ID | Merchant account ID, one per currency | confirmed |
| Stored card token | Payment method token, in the Vault | confirmed |
| Capture | Submit for settlement | confirmed |
Where to look
Disputes, settlement batches and transaction search all live in the Braintree control panel. PayPal-funded transactions also appear in the PayPal account, which is where a reconciliation gap usually turns out to be hiding.
Last verified: 2026-09-09 against Braintree's public developer documentation.
What they are: an acquirer and processor on one platform, in the same shape as Adyen. They hold acquiring licences in several regions and sell direct rather than through resellers.
| Question | Answer | Status |
|---|---|---|
| Which regions do they acquire in directly, for the card mix in question? | unconfirmed; ask per region | |
| Where they do not acquire, who do they route to? | unconfirmed | |
| Are a group's entities on one account or several? | unconfirmed |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Transaction | Payment, pay_… | confirmed |
| Stored card token | Source, src_… | confirmed |
| Single-use card token from the client | Token, tok_… | confirmed |
| Sub-account for a brand or entity | Processing channel | unconfirmed |
Last verified: 2026-09-09 against Checkout.com's public documentation.
What they are: a payment facilitator. Sellers on Square are sub-merchants under Square's own master account rather than merchants with their own acquiring relationship, which is what lets a market stall take a card the afternoon it signs up.
Everything in the facilitator section of this page applies here in its strongest form. The underwriting is Square's, the risk decision is Square's, and a seller who trips a risk rule finds out when a payout stops. There is no acquirer for that seller to appeal to, because the seller never had one.
| Question | Answer | Status |
|---|---|---|
| Who is the merchant of record on a Square sale? | unconfirmed; assume Square until the contract says otherwise | |
| What triggers a deposit hold, and how is it appealed? | unconfirmed | |
| Can a seller keep its card vault when it leaves Square? | unconfirmed; see stored cards and tokens |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Merchant | Seller | confirmed |
| Site or store | Location, location_id | confirmed |
| Auth-only | CreatePayment with autocomplete: false | confirmed |
| Capture | CompletePayment | confirmed |
Last verified: 2026-09-09 against Square's public developer documentation.
What they are: a processor, and through its bank partnerships an acquirer as well. Fiserv is the First Data business after the 2019 merger, so a lot of the US card estate runs on its platforms under other people's brands. A bank-branded merchant service is often Fiserv underneath.
Like Global Payments, the company is a collection of acquired platforms. Commerce Hub is the current unified API. Older integrations sit on Payeezy, CardConnect, Rapid Connect or Omaha, and those do not share a support queue with each other.
| Question | Answer | Status |
|---|---|---|
| Which platform is the integration on? | unconfirmed; Commerce Hub is the current one, and most estates are not on it | |
| Which bank is the sponsoring acquirer? | unconfirmed | |
| Is the contract with Fiserv, or with a bank that resells them? | unconfirmed; it changes who escalation goes to |
Their vocabulary
| Standard term | Their term | Status |
|---|---|---|
| Authorization or sale | Charge, on Commerce Hub | confirmed |
| Capture | Capture, against the original charge | confirmed |
Last verified: 2026-09-09 against Fiserv's Commerce Hub developer documentation.