Payment Service Providers (PSPs): Everything You Need to Know
A payment service provider is one contract that runs the merchant side of a card payment. This guide explains what a PSP does, how it differs from a gateway, an acquirer and an orchestration layer, and which PSP decisions quietly move revenue for subscription businesses.
Every guide to payment service providers is written by a payment service provider, so every guide ends at the same conclusion: choose us. This one is written by a company that does not process payments, so it can end somewhere more useful. It explains what a PSP actually is, what one decides on your behalf, and the handful of PSP decisions that quietly set the revenue ceiling for a subscription business.
What is a payment service provider?
A payment service provider (PSP) is a company that accepts electronic payments on your behalf under a single contract. Instead of you building connections to card networks and banks, the PSP supplies one integration that captures the card, requests approval from the issuing bank, and settles the money to you. Adyen, Stripe, Braintree, Checkout.com, PayPal and Worldpay are all PSPs.
The word to hold onto is bundle. Card acceptance is really three or four distinct jobs, and a PSP sells them stapled together so a business can start charging cards in days rather than months. That convenience is real. The trade is that the bundle also makes decisions for you, and most merchants never look at which ones.
What does a PSP actually do with a payment?
A PSP runs the merchant side of the payment chain: it captures the card details, sends the authorization request toward the card network, receives the yes or no from the issuing bank, and settles approved funds into an account that pays you out. The decision itself never belongs to the PSP. The issuing bank says yes or no, and the card network carries the messages between the two sides.
That boundary explains most PSP disappointment. When approvals drop, the cause usually sits on the issuer side of the line, in how the issuing bank reads your traffic. A PSP shapes what the issuer sees, through data quality, credentials and routing, but it cannot overrule the bank. Our guide to payment authorization walks the message path step by step.
PSP vs gateway vs acquirer vs orchestrator: which is which?
A gateway is the capture step: it takes card details and passes them on, the way a mail slot takes a letter. An acquirer is the bank side: it holds the merchant account the money lands in and carries the liability. A PSP is the bundle that includes both jobs under one contract. An orchestration layer is the level above all of them: one integration that routes each payment across several PSPs or acquirers.
| Term | The job in one line | When you would deal with it alone |
|---|---|---|
| Gateway | Captures the card details and passes them on | You picked a separate processor and only need the capture step |
| Payment processor | Formats and routes the authorization and settlement messages | Larger merchants contracting processing directly |
| Acquirer | The regulated bank holding the merchant account and the liability | Direct acquiring relationships at high volume |
| PSP | One contract bundling gateway, processing and acquiring access | Most businesses, most of the time |
| Orchestration layer | One integration routing each payment across several PSPs | Multi-provider setups that outgrew a single PSP |
Vendors blur these words freely, so test the function, not the label.
Why does the PSP choice matter more for subscription businesses?
Because a subscription business bills the same stored card again and again, every PSP behavior compounds. A one-time store meets its PSP once per customer. You meet yours every cycle, on autopilot, with nobody at the checkout to try a second card. Approximately 15% of recurring transactions are declined, per Visa and Mastercard data cited by Chargebacks911, and what happens to those declines is decided almost entirely by PSP defaults you may never have reviewed.
| What your PSP decides for you | Why it moves revenue |
|---|---|
| The retry schedule on failed rebills | Visa allows 20 reattempts per 30 days since May 2025 and Mastercard bills after 10 declines in 24 hours, so both the ceiling and the timing are rule-bound |
| Decline-code visibility | Many PSPs normalize a specific code like insufficient funds into a generic label, which hides which failures are recoverable |
| Credential updates on stored cards | 33 to 40% of cards are reissued each year, and whether updates reach you depends on the PSP's account updater and token support |
| Which acquirer sees your traffic | Approval rates vary by 10 to 25 percentage points across acquirers for the same card BIN |
The sources for those figures: the Visa Core Rules on the reattempt cap, Stripe on card reissuance, and Payneteasy on the acquirer spread. The pattern across all four rows is the same: the defaults are invisible until you measure them. Our breakdowns of decline code 51 and the card account updater cover the two largest levers in detail.
A compact example shows the scale. Fernwood Box, a subscription business billing 4,000 subscribers monthly at $40, sees roughly 600 failed rebills each cycle if its decline rate sits at the reported 15% average. Whether it recovers 100 of those or 300 is decided by retry timing, credential freshness and decline-code visibility, which are all PSP-level settings. The assumption in that math is only the published average; your own rate is knowable from your decline data.
How do PSPs charge?
Two models cover nearly every PSP. Blended pricing charges one flat rate per transaction, with the PSP's margin hidden inside it. Interchange-plus pricing (often written IC++) passes through the card network's actual interchange fee, the scheme fee, and a stated PSP markup on top. Blended is simpler to predict; interchange-plus is cheaper to audit, because you can see which part of the cost is the network and which part is the provider. For a subscription business the audit matters more than the simplicity, because rebill traffic is high-volume and repetitive, and a few basis points of hidden margin recur every cycle. Our guide to interchange fees explains what sits inside the pass-through.
When is one PSP not enough?
One PSP is the right start, and it stops being enough when the numbers say so, not when a sales deck does. Three signals mark the line. First, concentration risk: a single provider outage or account hold stops all revenue at once. Second, the approval spread: with rates varying 10 to 25 points across acquirers for the same BIN, a second provider is a live experiment in whether your traffic approves better elsewhere. Third, scale: routing each transaction to the provider most likely to approve it typically lifts approval rates by 10 to 15%, per Worldpay, and Primer's own research reports 87% of merchants considering orchestration within the next year. Vendor figures both, and both directionally consistent with the acquirer spread that creates the headroom.
The cost side is real: a second PSP means a second integration, split reporting, and reconciliation across two settlement schedules. The practical sequence is measurement first, then a second provider for a defined slice of traffic, then routing rules built on observed approval data. Our guides to a multi-acquirer strategy and the payment orchestration layer cover when each step pays for itself.
How should a subscription business choose a PSP?
Choose on rebill mechanics, not on checkout polish. Any modern PSP can render a clean payment form; far fewer expose the controls that decide recurring revenue. The checklist below is the subscription-specific test, and every item is verifiable in a sales call by asking to see the setting rather than hearing about it.
- Raw decline codes and the network advice code are available in exports, not only a normalized label.
- The retry schedule is configurable per decline code, and the defaults respect the network caps of 20 per 30 days on Visa and 10 per 24 hours on Mastercard.
- Account updater and network token support are included, with the price stated per update or per token.
- Merchant-initiated and customer-initiated transactions are flagged correctly for stored-credential rules.
- Pricing is interchange-plus, or the blended rate comes with a written breakdown you can audit.
- Settlement timing and reserve policies are stated for your vertical in writing.
- Data is exportable per transaction, because measuring a PSP requires data the PSP does not summarize for you.
Frequently asked questions
What is a payment service provider in simple terms?
A payment service provider is a company that accepts card payments for you under one contract. It captures the card details, asks the issuing bank for approval, and settles the approved money to your account. Stripe, Adyen, Braintree, PayPal, Checkout.com and Worldpay are well-known examples.
What is the difference between a PSP and a payment gateway?
A gateway is one function: it captures card details and passes them on. A PSP is a bundle that includes a gateway plus processing and access to an acquiring account. Every PSP includes a gateway, but a gateway alone is not a PSP.
Is Stripe a PSP or a payment processor?
Both, which is why the labels confuse. Stripe operates a gateway, processes transactions and provides acquiring access under one contract, and that bundle is what makes it a PSP. The useful question is never the label; it is which of the four jobs a contract covers.
Can a business use more than one PSP?
Yes, and larger subscription businesses often do. A second PSP adds redundancy and lets you route traffic to whichever provider approves it best, which typically lifts approval rates by 10 to 15% per Worldpay. The cost is a second integration and split reporting, so measure your approval data first.
Why do PSPs matter for subscription businesses specifically?
Because rebills are automatic, the PSP's defaults decide what happens when a stored card fails, and roughly 15% of recurring transactions are declined. Retry timing, decline-code visibility and credential updates are all PSP-level settings, and each one moves recoverable revenue every billing cycle.
How Beast can help
Beast is not a PSP and does not process payments, which is why it can measure PSPs honestly. It sits across the providers you already use and breaks approvals, declines and recoveries down by decline code, issuer, BIN, gateway, merchant ID and billing cycle, so PSP decisions stop being invisible defaults and become numbers you can act on. If you are weighing a second provider or questioning your current one, Beast payment routing or a conversation with the team is the place to start.