Skip to content

Explore by subject

PSP & Infrastructure

Select and operate your payment stack: choose the merchant model, evaluate providers, and check contracts, token portability and routing dependencies.

Briefings, grouped by decision

65 briefings in PSP & Infrastructure

Core PSP stack decisions

The foundational choices that shape everything downstream — operating model, vendor selection, contract terms, and token strategy.

Recurring and advanced payment infrastructure

The rails and primitives behind recurring payments, embedded finance, and account-to-account billing on infrastructure that bypasses cards.

Other briefings in this topic

Stack map

The payment stack decisions that compound

Each layer below has its own provider, its own contract, and its own operator implication. Compounding effects: the choice you make at one layer shapes the leverage you have at every layer downstream.

  1. 01

    Checkout

    Where payment intent starts — UX, conversion, and the first data captured.

  2. 02

    Gateway

    API, encryption, routing interface — the integration surface you maintain.

  3. 03

    PSP / Acquirer

    Authorisation, acquiring, settlement, and chargeback exposure sit here.

  4. 04

    Orchestration

    Redundancy, routing logic, and vendor abstraction across multiple PSPs.

  5. 05

    Token Vault

    Portability, recurring-payment resilience, and the deepest source of lock-in.

  6. 06

    Settlement

    Cash timing, reserves, and reconciliation complexity across providers and markets.

  7. 07

    Reporting & Reconciliation

    The source of truth across PSPs, markets, and currencies — and the audit trail.

Reference

Frequently asked

What is the difference between a payment gateway, a PSP, and an acquirer?

A gateway is the technical interface for transmitting payment requests. PSP offerings can bundle gateway, acquiring access, risk tools and reporting. An acquirer provides the acquiring relationship; a single provider can perform several roles. Confirm the contracting entity, supported markets and responsibility split for your particular arrangement.

When should a business use a Merchant of Record instead of a direct PSP?

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.

What are the most important clauses to check in a PSP contract?

Check reserve and release conditions, settlement timing, fee changes, termination rights, dispute responsibilities, data access and credential migration. Evaluate the terms against your own cash flow, operating responsibilities and exit plan rather than assuming a standard contract.

What is payment orchestration and when does it make sense?

Payment orchestration coordinates integrations and routing across providers. Start with a specific resilience or routing problem: which providers are eligible for the same traffic, what failover does after an uncertain result, and how the additional integration and operating cost compare with the expected benefit. There is no universal processing-volume threshold.

How do network tokens differ from PSP vault tokens — and does it matter?

A PSP vault token is a reference within that provider system. A network token has its own provisioning, domain and lifecycle arrangements. Neither label alone establishes portability: check credential export and import, token-requestor arrangements, provider support and customer reauthentication requirements. Network-token lifecycle updates do not eliminate every cause of recurring-payment failure.

PSP selection, acquiring structure, gateway architecture, and routing logic are not commodity decisions — they directly determine authorisation rates, processing costs, vendor leverage, and how quickly an operator can adapt when a market shifts. The stack architecture you build in year one is often the one you’re working around in year three.

Reserves change cash availability; provider-specific credentials can complicate a migration; a single-acquirer setup concentrates outage exposure. Model those dependencies using your own contract, migration plan and eligible routing paths. None establishes a universal churn rate or authorization improvement.

The briefings in this topic cover the full stack: how to evaluate and choose a PSP, how to structure multi-acquirer routing for resilience and rate improvement, how to read a PSP contract before you sign it, and when the complexity of direct acquiring outweighs the benefits of staying with a payment facilitator or merchant of record. The framing question throughout is the same: at every layer of the stack, who controls the next decision — you, or your PSP?