How Payment Service Provider (PSP) Works
A PSP sits between your checkout and the global payments infrastructure, translating a customer's payment intent into a settled transaction in your bank account. The flow involves several coordinated steps across technology and banking systems, all abstracted away by the PSP into a single API or hosted checkout.
Customer initiates payment
At checkout, the customer enters card details or selects an alternative payment method. The PSP's payment gateway captures this data over an encrypted TLS connection and tokenizes the card number to protect sensitive information in transit.
Authorization request is sent
The PSP formats an authorization request and routes it to the relevant card network (Visa, Mastercard, etc.) or payment scheme. The network forwards the request to the cardholder's issuing bank, which approves or declines based on funds, fraud signals, and account status.
Response returned to merchant
The issuing bank's decision (approve, decline, or refer) travels back through the card network to the PSP, which relays it to your checkout in real time — typically within 1–3 seconds. The merchant's site displays a confirmation or error to the customer.
Capture and clearing
For card-present or deferred capture flows, a separate capture request is sent — either immediately or at shipping. The PSP batches captured transactions and submits them to the card networks for clearing, where funds are formally moved between banks.
Settlement to merchant
The acquirer receives net funds from the card networks and deposits them into the merchant's account, minus interchange fees, scheme fees, and PSP margins. Settlement windows vary: typically T+1 to T+3 for most PSPs, though some offer instant payout products.
Tokenization is handled by the PSP
Most PSPs replace raw card numbers with a PSP-specific token immediately after capture. This means your systems never store PAN data, significantly reducing your PCI DSS compliance scope.
Why Payment Service Provider (PSP) Matters
The PSP model fundamentally changed how businesses access payments infrastructure. Before PSPs emerged, a merchant needed separate contracts with a bank, a gateway vendor, a fraud tool, and a currency conversion service — a process that could take weeks and required technical integrations with each. PSPs collapsed this into a single API, making accepting payments accessible to businesses of any size.
The impact is measurable. According to the Worldpay Global Payments Report, digital commerce payment volumes exceeded $9 trillion globally in 2023, with PSPs processing the vast majority of card-not-present transactions. A single percentage-point improvement in authorization rates — something a well-chosen PSP can deliver through local acquiring and network optimization — translates directly to revenue: for a merchant processing €10M annually, that is €100,000 in recovered sales.
Authorization rates vary significantly by PSP. Research from Checkout.com and industry benchmarks consistently show that PSPs with local acquiring in a region outperform cross-border routed transactions by 3–8 percentage points. For merchants expanding internationally, this makes PSP selection a strategic revenue decision, not just an infrastructure one.
Beyond card payments
Modern PSPs support dozens of alternative payment methods (APMs) — iDEAL in the Netherlands, Bancontact in Belgium, PIX in Brazil, UPI in India. Access to these methods through a single integration can meaningfully increase conversion in local markets.
Payment Service Provider (PSP) vs. Payment Facilitator
PSPs and payment facilitators are often confused because both let merchants accept payments under a single contract. However, their structures and risk models are fundamentally different.
| Dimension | Payment Service Provider (PSP) | Payment Facilitator (PayFac) |
|---|---|---|
| Merchant account | Dedicated or shared depending on model | Always shared (sub-merchant under master MID) |
| Underwriting | Full KYB before activation | Light onboarding; risk managed post-activation |
| Onboarding time | Days to weeks | Minutes to hours |
| Settlement | Directly to merchant or via PSP | Via PayFac, then disbursed to sub-merchant |
| Liability | Shared with merchant | PayFac bears primary fraud/chargeback liability |
| Typical fit | Mid-market and enterprise merchants | Marketplaces, SaaS platforms, SMBs |
| Examples | Adyen, Worldpay, Checkout.com | Stripe (PayFac model), Square, PayPal |
The distinction matters when negotiating contracts and understanding who is liable when a chargeback or compliance issue arises. Large merchants with complex risk profiles typically prefer a direct PSP relationship over a PayFac structure.
Types of Payment Service Provider (PSP)
PSPs are not a monolithic category. Different models serve different merchant profiles, and understanding the landscape helps you choose the right partner.
Full-stack PSPs with proprietary acquiring — Companies like Adyen and Checkout.com are licensed acquirers in multiple regions, meaning they own the full payment chain. This gives them more control over authorization logic, pricing, and settlement speed. Best for enterprise merchants who need global acquiring with consistent data and reconciliation.
Gateway-only PSPs — Some providers focus purely on the technology layer and rely on partner acquirers for settlement. They offer flexibility in choosing your acquirer but require more integration work and separate banking relationships.
PayFac-model PSPs — Stripe and Square operate as payment facilitators, aggregating merchants under their master accounts. This dramatically reduces onboarding friction but gives the PSP significant control over fund flows and account holds.
Regional PSPs — Providers like Mollie (Europe), Razorpay (India), or Mercado Pago (Latin America) are optimized for specific geographies. They offer strong local payment method coverage and local currency settlement that global PSPs may not match.
Vertical PSPs — Some PSPs specialize in high-risk verticals (travel, gaming, regulated industries) and are experienced in the chargeback patterns and compliance requirements of those sectors.
Best Practices
Every PSP relationship involves both merchant-side operations and developer-side integration decisions. Getting both right determines whether you extract full value from your provider.
For Merchants
Negotiate interchange-plus pricing once you exceed €500K in annual volume. Blended flat-rate pricing is simple at low volume but becomes expensive as you scale. Interchange-plus passes through the exact card network cost and charges a fixed markup, giving you visibility and reducing effective rates.
Audit your authorization rate monthly by card type, country, and BIN range. PSPs provide this data in dashboards or API reports. Declines are not random — patterns reveal whether the issue is with your PSP's acquiring relationships, your fraud rules, or specific card issuers.
Understand your reserve and payout terms before going live. Some PSPs hold a rolling reserve (typically 5–10% of volume for 90–180 days) for higher-risk merchants. Cash flow planning must account for this.
Map your chargeback dispute process before you need it. PSPs have different SLAs for submitting representment evidence. Know the deadlines and build internal workflows to gather evidence (delivery confirmation, customer communication logs) quickly.
For Developers
Use webhooks, not polling, for payment state changes. PSPs emit webhook events for authorization, capture, refund, dispute, and settlement state changes. Polling the API for status is fragile and introduces latency. Build idempotent webhook handlers that deduplicate events using the PSP's event ID.
Implement 3DS2 handling explicitly in your integration. Do not rely on the PSP to handle all 3DS flows invisibly. Understand when a frictionless flow is applied vs. a challenge is triggered, and ensure your checkout UX handles challenge redirects gracefully to avoid abandoned transactions.
Store the PSP's transaction reference, not just your internal order ID. When resolving disputes or debugging settlement discrepancies, the PSP's own transaction ID is essential. Always persist it alongside your order record at authorization time.
Test failure paths in staging. Every PSP provides test card numbers for declined transactions, insufficient funds, and expired cards. Automated tests should cover these paths — not just happy-path authorizations.
Common Mistakes
Choosing a PSP based only on headline pricing. The advertised rate rarely tells the whole story. Currency conversion fees, chargeback fees, refund fees, and monthly minimums can add 0.5–1.5% to your effective rate. Always model the total cost of acceptance against your actual transaction mix.
Using a single PSP for all markets without evaluating local acquiring. A European PSP processing transactions in Southeast Asia often routes cross-border, which increases decline rates and latency. Merchants expanding to new regions should evaluate PSPs with local acquiring presence — or implement payment orchestration to route to the best acquirer per market.
Ignoring the PSP contract's termination and fund-hold clauses. PSPs can freeze merchant accounts if fraud or chargeback rates spike, sometimes without immediate notice. High-volume merchants should have a secondary PSP ready to receive traffic and maintain sufficient operating capital to weather a hold period.
Over-tightening fraud rules to minimize chargebacks. Aggressive fraud filters reduce chargebacks but also block legitimate transactions. False positives are invisible in standard PSP dashboards but real to your customers. Track and optimize your false-positive rate alongside your fraud rate.
Not reconciling PSP payouts against your order system. Settlement files from PSPs include deductions for fees, refunds, and chargebacks. Merchants who only check the net bank deposit miss discrepancies that accumulate into significant revenue leakage over time.
Payment Service Provider (PSP) and Tagada
As merchant businesses grow and PSP limitations emerge — authorization rate ceilings, currency gaps, outage risk — a single PSP relationship becomes a bottleneck. Tagada is a payment orchestration platform that sits above your PSPs and turns a static integration into a dynamic routing layer.
Use Tagada to get more from your PSPs
With Tagada, you connect multiple PSPs once and define routing rules that send each transaction to the optimal provider — by card BIN, country, amount, or risk score. If one PSP returns a soft decline, Tagada retries automatically on a backup PSP. This typically recovers 2–5% of transactions that would otherwise be lost, without requiring changes to your checkout or order management system.
Tagada also normalizes the data models and webhook formats across PSPs, so your engineering team works with a single API regardless of how many providers are connected downstream. Reconciliation, reporting, and dispute management are unified in one interface — eliminating the operational overhead of managing multiple PSP portals and settlement files independently.