PSP, Acquirer, Merchant of Record: the model you choose decides what you actually do every day

Most founders accept payments without ever realizing they made a structural choice.

When you sign up with Stripe, Adyen, Checkout.com, your local PSP, or your business bank's payment offering, you sign up for a model. The model is invisible because it's the default one. Every Western founder lands on it. Every blog post about "how to accept payments online" assumes it. So nobody talks about it.

There's another model. It has existed for decades, it's used by Apple, Microsoft, Steam, and most of the global digital goods economy, and it changes everything about what you are responsible for vs. what someone else is responsible for.

This article is about understanding the difference. Not picking a side. Just being aware of what you actually signed up for, because once you know, your operational priorities change.

The PSP / Acquirer model

In the Payment Service Provider or acquirer model, you are the merchant. Legally, contractually, in the eyes of the card networks, of the tax authorities, of the customer's bank. The PSP or acquirer is your service provider. They give you the technical rails to accept cards, but the merchant relationship belongs to you.

Concretely, that means:

• You sign the merchant contract with the acquirer. You agree to its terms, its reserves, its monitoring, its termination clauses.
• You hold the card network agreements. When Visa or Mastercard fines a merchant for excess chargebacks, that fine is yours.
• You bear the chargeback risk. Every dispute hits your account. Every refund comes out of your float. Every fraud loss is yours to absorb or fight.
• You collect and remit local taxes. VAT in the EU, sales tax in 50 US states, GST in dozens of jurisdictions. You register, you file, you remit. Every market you sell into adds a compliance line item.
• You manage acceptance rate. When the issuing bank declines a transaction, the loss is yours. The retry logic, the BIN intelligence, the 3DS strategy, the network tokens, all of it is yours to build or buy.
• You carry the ban risk. If your chargeback ratio spikes, your acquirer cuts you off. Overnight. No notice. You scramble to find a new processor while your revenue goes to zero.
• You handle FX. When you sell in EUR and your bank account is in USD, the conversion is yours, with whatever spread your bank or PSP is taking.

The trade-off is control. You own everything. You can negotiate, optimize, multi-route, switch providers, build custom flows. The PSP gives you the rails. Everything else is yours to shape.

The cost is operational weight. As you scale internationally, the list above stops being a side topic and becomes a department. By the time you're at $10M ARR with significant cross-border volume, you've hired or contracted out: payments engineering, fraud operations, tax compliance, finance reconciliation, sometimes a chargeback team. Six-figure annual cost minimum, often seven.

The Merchant of Record model

In the Merchant of Record model, a third-party entity becomes the legal merchant of record vis-à-vis the card networks. You become a supplier to that entity. The MoR sells your product to your customers, collects the money, and remits proceeds to you.

Concretely, what that does to the list above:

• The MoR signs the merchant contract with the acquirer. The terms, the reserves, the monitoring, the termination clauses, all on them.
• The MoR holds the card network agreements. Visa and Mastercard see the MoR as the merchant. Network fines are theirs.
• The MoR bears the chargeback risk. Every dispute hits their account. Some MoRs pass losses back to merchants contractually, some absorb them. The acquirer-facing risk is theirs.
• The MoR collects and remits local taxes. VAT, sales tax, GST, in every market they operate. You don't register anywhere, you don't file anywhere, you don't remit anywhere. You receive a single payout, net of taxes.
• The MoR manages acceptance rate. Their stack, their fraud rules, their retry logic, their network tokens. You inherit whatever quality they offer.
• The MoR carries the ban risk. If their chargeback ratio spikes across their platform, the acquirer cuts them off. You hope they have backups (most don't, more on that in another article).
• The MoR handles FX. They collect in 30 currencies, pay you out in one. Their spread, their schedule.

The trade-off is the inverse: you trade control for operational simplicity. You don't own the merchant relationship. You can't negotiate with the acquirer directly because there is no direct relationship. You inherit the MoR's stack, with its strengths and its limits. You're locked into their tax decisions, their payout schedule, their fraud policy, their geographic footprint, their business model approvals.

The benefit is everything off the list above is no longer your problem. You ship product, you integrate one API, you receive net payouts. No payments team, no tax registrations, no chargeback war room, no acquirer negotiations.

What this looks like from the customer's chair

This is the part founders almost always get wrong before they understand the model.

From the buyer's perspective, there is no difference whatsoever. They land on your checkout. They enter their card. They get charged. They get the product.

The card statement might show the MoR's name as the descriptor instead of yours, but most MoRs let you customize that. The receipt comes from the MoR's domain or yours, depending on configuration. Customer support flows can be set up either way.

The customer experience is identical. The model only changes things on your side, not theirs. It's a back-end architectural decision, not a front-end one. The difference is purely technical and legal. Your operations team feels everything. Your customer feels nothing.

Most founders default to "MoR will hurt my brand" because the word Merchant of Record sounds intrusive. It isn't. Apple's App Store is a MoR. When you buy an app, you're not buying it from the developer, you're buying it from Apple. Apple is the merchant. The developer is Apple's supplier. That structure has zero impact on the user experience and has powered the largest digital goods economy in history.

Why this matters when you're scaling cross-border

The two models look similar at $1M ARR domestic. They diverge sharply the moment you push internationally.

In the PSP model, every new geography adds a compliance burden, a tax obligation, an acceptance rate problem to debug, an FX line item, often a local entity to incorporate if you want competitive rates. By the time you're selling in 20 countries, the operational stack to support that is large, expensive, and full-time.

In the MoR model, every new geography is a checkbox in a config file. The MoR has already done the registrations, has the local rails, has the tax engines, has the support of the acquirer for that vertical. You go from "we accept payments in 3 countries" to "we accept payments in 80" in an afternoon.

That's the structural reason MoRs exist. The category was built for the businesses that are too small to build a global payments operation themselves but want to sell globally anyway. Which, increasingly, is most digital businesses today.

What it does not mean

A few things the MoR model is often confused with:

• It does not mean your prices are higher. You set your prices. The MoR's fee comes out of your margin, not the customer's wallet (in most configurations).
• It does not mean you lose your brand. Checkout, receipts, descriptors, support flows, all customizable in any serious MoR.
• It does not mean you lose data. Or rather, it shouldn't. Some MoRs lock customer data, some don't. This is a contractual question, not a model-level one.
• It does not mean you can't switch. Or again, it shouldn't, depending on how the MoR handles tokens. This is also a contractual and architectural question.

The model itself is neutral. The implementations are not. Most of the criticism aimed at "MoRs" is actually criticism aimed at specific MoR implementations that made bad choices on data portability, fees, transparency, or vertical coverage. The model and the implementation are two different conversations.

So which one is right for you?

Honestly, it depends on three things.

One, your geographic footprint. If 90% of your revenue is domestic and likely to stay that way, the PSP model is fine. You won't gain enough from outsourcing tax and compliance to justify the trade-offs. If you start to sell in 2+ countries, the MoR math starts looking very different. At 5+, it's not a decision anymore.

Two, your team. If you have, or are willing to hire, payments engineers, tax counsel, compliance ops, fraud analysts, the PSP model gives you the most upside. You'll squeeze every last bp out of your stack. If you don't have that team and don't want to build it, the MoR model lets you ship.

Three, your vertical. SaaS and digital goods are well-served by both models. Marketplaces, regulated verticals, physical goods with local fulfillment, embedded finance, often need the control the PSP model gives. Check what the MoRs in the market actually accept before assuming the door is open.

The trap is choosing by default rather than by design. Most founders default to PSP because it's what Stripe sold them on day one, and they discover the operational cost three years later when international revenue is 40% of the top line. Some founders default to MoR because the pitch sounds easier, and they discover the lock-in two years later when they want to switch and can't.

Either model can be the right one. Pick the one that matches what you actually want to spend your operational energy on.

A note, since this is an article published on our own outlet. We picked the MoR side of this debate ourselves, and we built Inflowpay to run on it. The reason isn't that the MoR model is universally better. It's that the implementations available on the market today don't actually deliver what the model promises on paper.

Most existing MoRs run on a single PSP underneath, which means they inherit one acquirer's acceptance rate, one acquirer's fees, and one acquirer's ability to cut them off overnight. Most lock customer data and tokens, which means leaving costs you most of your MRR. Most price opaquely, which means the 5% headline becomes 9-12% all-in once you've signed. Most exclude marketplaces, physical goods, and emerging markets, which means the "global reach" argument has a long list of asterisks.

We built around those gaps. Multi-acquirer routing instead of single-PSP dependency. Portable customer data. One transparent rate. Marketplaces, physical goods, and most geographies onboarded. A settlement layer that's continuously auditable, so you can verify where your money is at any moment instead of trusting a dashboard.

If the MoR model fits your business after reading the trade-offs above, that's the version of it we think makes sense. If the PSP model fits better, that's a fully reasonable answer too, and you don't need us to tell you to use Stripe.

‍