PSP & Infrastructure

A payment gateway is the technical layer that transmits payment data between your checkout and the acquiring bank — it handles encryption, routing, and the API interface. A PSP (Payment Service Provider) bundles the gateway with acquiring, often adding fraud tools, reporting, and local payment method support in a single contract. An acquirer (or acquiring bank) is the licensed financial institution that holds the merchant account, settles funds, and takes on chargeback liability. Most merchants deal with a PSP that packages all three functions — Stripe, Adyen, and Checkout.com are PSPs with their own acquiring licences in most markets they operate in.

A Merchant of Record (MoR) makes sense when tax and compliance complexity exceeds your team's capacity to manage it. If you sell digital goods internationally, an MoR (Paddle, Polar, FastSpring) handles VAT registration in 100+ countries, local compliance, and tax remittance on your behalf — you invoice the MoR, not the customer. The tradeoff is cost (MoR take rates are typically 4–6% vs 1–3% for direct PSP) and control (the MoR owns the customer relationship for payment purposes). At scale above roughly $3–5M ARR with international digital sales, most operators evaluate whether direct PSP with dedicated tax infrastructure is more economical.

The five highest-risk clauses: (1) Rolling reserve — how much of your funds the PSP holds and for how long; (2) Termination rights — whether the PSP can terminate with minimal notice and freeze funds; (3) Data portability — whether you can export your tokenised card vault if you switch PSPs; (4) Fee change notice period — how much notice you get before rate increases; (5) Chargeback liability — what thresholds trigger account review or termination. Most PSP contracts are heavily weighted toward the PSP's risk management needs, not merchant flexibility. The contracts for Stripe, Adyen, and Checkout.com all have specific red flags documented in the PSP contract red flags briefing.

Payment orchestration is a middleware layer (Spreedly, Primer, Gr4vy) that sits between your checkout and multiple PSPs, routing transactions intelligently — by geography, payment method, transaction value, or real-time success rates. It makes sense when you have: (1) multi-PSP redundancy needs (if one PSP goes down, failover automatically); (2) market-specific acquiring requirements (needing local acquirers in different countries for better auth rates); or (3) complex routing logic that your primary PSP can't express. For single-PSP merchants below roughly $10M in processing volume, orchestration adds integration overhead without proportional benefit. At scale, it is a meaningful authorisation rate and cost lever.

A PSP vault token (Stripe's tok_xxx, Adyen's recurring reference) is specific to that PSP — it represents your customer's card as stored in that PSP's system. If you switch PSPs, the token is useless and you have to re-vault all cards (expecting 10–25% customer drop-off during migration). A network token (Visa Token Service, Mastercard MDES) is issued by the card scheme and works across any PSP that supports network tokenisation. Network tokens also self-update when cards are reissued, eliminating subscription churn from card expiry. The practical implication: operators with large stored-card subscriber bases should prioritise PSPs that automatically provision network tokens, as it reduces both migration lock-in and recurring billing failure rates.