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) becomes the seller of record and takes on registering, collecting and remitting indirect tax in the jurisdictions it supports — the coverage is provider-specific, so check the list rather than assuming it is global. The trade-off is cost, since an MoR take rate sits above direct PSP processing, and control, since the MoR owns the customer relationship for payment purposes. There is no revenue threshold at which the model stops working: the trigger is structural, not a GMV milestone, and it arrives when the MoR's constraints cost more than the compliance infrastructure that would replace it.

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.