When should you change your payments model?

When your monetization is capped by the model itself rather than the deal or the execution. Common triggers: you are referring payments and want to own the spread, you need control over onboarding and the merchant experience that only ownership gives, you have reached the volume where heavier-model economics clearly win, or you need capabilities your current model cannot reach. Optimize first; change the model only when optimization has hit its ceiling.

What are the embedded payments models?

A ladder of increasing economics and responsibility: ISV referral (refer merchants, earn a share), enhanced residual (a larger cut for doing more of the work), PayFac-as-a-Service (own the experience and most economics while a provider carries the compliance and infrastructure), and full PayFac (own the economics, the risk and the regulatory burden). Each rung trades more control and margin for more operational and compliance load.

What is the difference between the referral model and payment facilitation (PayFac)?

Under the referral model (the ISV referral model) you refer merchants to a provider and earn a share, with the provider owning onboarding, support, risk and compliance. Under payment facilitation you become the payment facilitator (PayFac), owning the merchant experience and the economics, and taking on more of the underwriting, risk and compliance load. Payment facilitation earns more per transaction; the referral model carries less responsibility. Moving from referral to PayFac is the most common model change platforms make.

What does changing your payments model cost?

Four categories: direct migration (engineering, integration, parallel-running), merchant churn during re-boarding, opportunity cost from diverted product focus, and transition risk. Because moving models usually means moving infrastructure, the indirect costs typically dwarf the direct ones, and the total is rarely under 250,000 dollars for a platform with meaningful volume.

Should you optimize or change your payments model?

Optimize first. Most near-term upside is in pricing, activation and failed-payment recovery inside the model you already run, and those wins are cheap and reversible. Change the model only when optimization is genuinely worked and the ceiling is structural, meaning the model itself limits what you can earn or control.

Should You Change Your Payments Model? Referral vs PayFac

Every platform that monetizes payments eventually hits a plateau. The first response should be to optimize the model you already run, since most near-term upside is in pricing, activation and recovery, and those wins are cheap and reversible. But optimization has a ceiling. When you have taken those wins and the number still will not move the way the business needs, the constraint is no longer the deal or the execution. It is the model itself.

That is a different and much larger decision. Changing your payments model is not a better rate or a new vendor; it is a change in how much of the payments economics you own, and how much of the risk and compliance load you carry to own it. It is one of the highest-return moves a platform can make, and one of the most expensive to get wrong. Here is how to tell whether you are ready for it.

Change your payments model when your monetization is capped by the model itself rather than the deal or the execution. The common triggers: you refer payments and want to own the spread, you need control over onboarding and the merchant experience that only ownership provides, you have reached the volume where heavier-model economics clearly win, or you need capabilities your current model cannot reach. Optimize first; change the model only when optimization has genuinely hit its ceiling.

What model are you actually on?

Most platforms know their provider better than they know their model. The payments models form a ladder, and each rung trades more control and more economics for more operational and compliance responsibility. The move most platforms are weighing, and the one behind the common "payfac vs ISV" and "payment facilitation vs referral" questions, is a step from referring payments to facilitating them.

ISV referral (the referral model)

You refer merchants to a payments provider and earn a share of the revenue. Lowest effort, lowest economics, lowest risk. The provider owns the relationship, the onboarding, the support and the compliance. This referral model is the right starting point for most platforms, and the one most commonly outgrown.

Enhanced residual

The same basic structure with a larger cut, usually because you take on more of the work: some of the merchant experience, some of the servicing. More economics, still limited control. A reasonable step up that stops short of ownership.

PayFac-as-a-Service

You own the merchant experience and most of the economics while a provider carries the heaviest compliance and infrastructure. You get much of the upside and control of being a payment facilitator without standing up the full apparatus. For many platforms this is the destination, not a way station. See PayFac-as-a-Service for the detail.

Full PayFac

You own the economics, the risk and the regulatory burden. The most control and the most margin, and the most to carry: underwriting, compliance, funding, and support all become yours. Right for a narrower set of platforms than the market's enthusiasm suggests. The comparison in PayFac vs ISO and the broader question of whether your platform should monetize payments at all are worth reading before you commit.

What are the signals you have outgrown your model?

Not every frustration is a model problem; many are optimization problems in disguise. These are the ones that tend to be structural, meaning no amount of tuning the current model resolves them.

Signal 1: You are leaving the spread on the table

You refer payments and watch someone else earn the margin on volume you originated. If the economics you are giving up would materially change your P&L, and you have the scale to support a heavier model, referral is now costing you more than it saves.

Signal 2: Your monetization is capped by the model, not the market

You want to price, package or bundle payments in a way your current model does not allow. When the ceiling on what you can charge or how you can structure it is set by your provider's model rather than by your customers, you have a structural constraint.

Signal 3: You need control over the merchant experience

Onboarding, boarding UX, funding timing, the support relationship. If activation or merchant experience is capped by a flow you do not own and cannot change, ownership is the only real fix. Rule out the fixes inside your control with the activation playbook first; if the ceiling remains, it is the model.

Signal 4: You have reached the volume where heavier economics win

Every rung up the ladder has a volume at which its economics overtake the rung below, net of the added operational cost. Past that point, staying on the lighter model is a choice to earn less. The Margin Multiplier is built to find that crossover for your numbers.

Signal 5: You need capabilities the model cannot reach

New geographies, a regulated vertical, a funding or risk structure your current model does not support. These are structural gaps rather than negotiable ones, and they force the model question regardless of where your volume sits.

What does changing your model cost?

Because moving up the ladder usually means moving infrastructure, model change carries the full weight of a migration. Model it honestly before you decide; it is almost always larger than the first estimate.

Direct Migration Cost

Engineering integration + parallel-running fees + project management

Typical range: $50K-$200K for a mid-size platform; higher for complex integrations

Merchant Migration Cost

Re-boarding effort + communication + churn from friction

Expect 5-15% merchant churn during migration; higher if boarding flow is painful

Opportunity Cost

Product roadmap time displaced + GTM focus consumed

Typically a full quarter of product team capacity; longer for the largest moves

Risk & Compliance Cost

New underwriting and compliance load + chargeback continuity + data portability

Grows with every rung up the ladder; a full PayFac move takes on the most

The total is rarely under $250K for a platform with $25M+ annual GMV, and a move to full PayFac carries an ongoing compliance and operational cost that outlasts the migration itself. The heavier the rung, the more the recurring burden, not just the one-time project, has to be justified by the economics.

Optimize or change: the decision line

The ceiling is the deal or the execution: optimize, do not change models. Rate, activation and recovery still have room, and capturing it is cheaper and reversible. Start with getting more from your current model.
The ceiling is economic and you have the scale: move one rung, not three. Referral to enhanced residual, or residual to PayFac-as-a-Service, captures most of the upside for a fraction of the load of going all the way to full PayFac.
The ceiling is control or capability: change the model, because no deal fixes a structural gap. Match the rung to what you actually need to own, not to the most ambitious option.
You are tempted by full PayFac: be sure the recurring compliance and risk burden is justified by the economics and that you have the operational appetite to carry it. For many platforms PayFac-as-a-Service captures most of the benefit without the weight.

The migration playbook

If you have decided to move, execution determines whether the economics materialize or evaporate in operational chaos. Six steps:

Step 1: Quantify the gap, economic and structural

Document the economics of your current model versus the target rung, multiplied by projected volume over 36 months, and name the structural gains (control, capability) that will not show up in the rate math. The financial case has to stand on its own; the structural gains justify the effort to the team.

Step 2: Run a real evaluation across providers

Even with a preferred target, get competitive terms from at least two alternatives. It changes the conversation with your preferred provider and surfaces capability differences you would otherwise miss. The structural process is in how to choose an embedded payments provider.

Step 3: Pilot with a small merchant cohort

Choose merchants representative of your mix and willing to be partners. Run real volume through the new model for 30 to 60 days. The pilot surfaces integration issues, validates the economics and builds operational confidence before full cutover.

Step 4: Settle runoff terms with your current provider

Before notifying merchants, agree what happens to existing settlements, how long data is held, and where chargeback liability sits during the transition. Get it in writing while the relationship is still intact, not after it sours.

Step 5: Phased migration over 3 to 6 months

Never move the entire base in one weekend. Migrate by segment, smallest merchants first, then mid-tier, then top accounts. Each wave lets you fix issues before they compound. Over-communicate; most of the friction merchants feel is about communication, not the technical change.

Step 6: Decommission cleanly

Keep the old integration alive for 60 to 90 days post-cutover for late chargebacks, reconciliation and disputes. Then decommission, revoke credentials, and archive the data. A half-migrated state is the worst possible outcome.

The right time to change models is rarely when it feels most urgent. It is when optimization has been exhausted, the math has been clear for a quarter, and the operational readiness is in place to execute cleanly.

Changing your model has a strong reversibility curve: cheap and recoverable before merchant migration begins, expensive and largely irreversible after. If optimization still has room, take it first and wait. If the ceiling is structural, the longer you carry a model you have outgrown, the more it costs.

The Margin Multiplier quantifies the economics of each rung against your volume. For the operational scenario and migration planning, that is what the advisory engagement is for.

Should You Change Your Payments Model?