It is one of the first questions a platform asks once payments starts pulling real revenue: how much volume do we need before we go become a payment facilitator? People want a number. Ten million in GMV, fifty million, a billion. Something clean they can put on a slide and point to as the moment the model flips.

The number does not exist, and chasing it sends you down the wrong road. The question assumes registration is the destination and volume is the on-ramp. Neither is true. Registration is a specific operational decision with real costs, and for most platforms the lighter models already deliver the economics they think registration will unlock.

There is no magic volume number. PayFac-as-a-Service captures most of the economics of registration without the compliance, underwriting and headcount load, so becoming a registered payment facilitator is a control and risk-appetite decision, not a GMV milestone. Most platforms asking how much volume they need are solving the wrong problem. The real triggers are control over the stack, a specific vertical or risk reason and economics that only pencil at very large scale.

How much volume do you need to become a payment facilitator?

The honest answer is that there is no fixed number, and no responsible person can give you one without knowing why you are asking. Operators expect a threshold because that is how most other build-versus-buy decisions work: at some scale the fixed cost of owning a thing beats the variable cost of renting it, and there is a crossover point you can compute. Payment facilitation feels like it should have the same clean crossover.

It does not, because the thing you would be buying with registration is not mostly economics. It is control and liability. You can process an enormous amount of volume through a managed model and never hit a point where the math alone forces you to register. Platforms discover this the hard way when they build the case and the payback keeps not arriving. If you want the underlying definition first, start with what a payment facilitator actually is.

Why the GMV-threshold question is the wrong frame

The frame breaks because it treats full registration as the only way to capture payments economics, when it is not. PayFac-as-a-Service closes most of the economic gap. Under a managed model you already earn the bulk of the spread, own the merchant relationship and set your own pricing. The marginal basis points you would pick up by carrying the full registration yourself are smaller than most platforms assume, and they arrive with a large fixed operating cost attached.

So the interesting comparison is never referral versus full PayFac. It is PayFac-as-a-Service versus full registration, and on that comparison the gap is narrow enough that volume alone rarely justifies the jump. The model comparison lays out where each option earns its keep.

What PayFac-as-a-Service captures vs full registration

With PayFac-as-a-Service you own the merchant experience and most of the economics. You onboard and price your merchants, the payments live inside your product, and you keep the majority of the spread. What you do not carry is the heaviest load. A provider is the registered facilitator, so the provider holds the sponsor bank relationship, the underwriting apparatus and the compliance obligations that come with being the entity of record. You get the upside of embedded payments without becoming a regulated payments company overnight.

Full registration flips that. You carry all of it. The economics you keep go up at the margin, but so does everything else: the sponsor bank relationship you have to source and maintain, the underwriting and risk decisions you now own outright, and the compliance surface that used to be someone else's problem. The PayFac-as-a-Service model exists precisely because most platforms want the first outcome, not the second.

You can process an enormous amount of volume through a managed model and never hit a point where the math alone forces you to register.

The real cost of registering

Registration is not a one-time filing. It is a standing operation. You need dedicated headcount in risk, compliance and underwriting, because those functions do not run themselves and cannot be a side project for an engineer. You need tooling for onboarding, monitoring and reporting, which you either build or buy, and both cost real money and time. You carry ongoing audits rather than a single certification. And you have to source and keep a sponsor bank relationship, which is its own commercial and relationship burden.

None of that scales down. A platform doing a modest volume pays roughly the same fixed operating cost as a much larger one, which is exactly why the economics only start to pencil at real scale. The full picture of that load is in the compliance requirements for registered facilitators.

What actually triggers full registration

Three things trigger it, and volume is rarely the headline reason. The first is control. You want to own the stack and the risk decisions, set your own underwriting appetite and not route those calls through a provider. The second is economics that only work at very large scale, where the fixed operating cost finally divides across enough volume to beat the managed model. The third is a specific structural reason, usually a vertical the PayFac-as-a-Service provider's sponsor bank will not support, so the managed path is closed to you and registration becomes the way in rather than the upgrade.

Notice that a GMV milestone appears nowhere on that list as a cause. Scale can make the economics of registration viable, but it is the control and risk reasons that make it necessary. Volume is a condition, not a trigger.

So should your platform register?

Most platforms never should. The ones that register well did it because they needed control they could not get any other way, or because their risk appetite and vertical demanded it, not because a number told them to. Registering to chase a marginal basis point or two, without a control or risk reason underneath it, is how platforms end up owning a compliance operation they did not want and cannot staff.

Start with a referral model or PayFac-as-a-Service, capture the economics that path gives you, and register only when the control, risk or scale reasons are real and specific to your situation. If you are weighing whether you are actually ready, the readiness question is the right next read.

Frequently Asked Questions

How much GMV do you need to become a payment facilitator?

There is no fixed threshold. PayFac-as-a-Service captures most of the economics, so registration is a control and risk decision, and on economics alone it rarely pencils even well into the billions in volume.

Is PayFac-as-a-Service the same as being a payment facilitator?

With PFaaS you get most of the merchant experience and economics, but the provider is the registered payment facilitator that carries the compliance and infrastructure load.

What does it cost to become a registered payment facilitator?

Real headcount in risk, compliance and underwriting, tooling to build or buy, ongoing audits and a sponsor bank relationship. It usually only makes sense at large scale or when you need control the lighter models cannot give you.

Why do platforms become payment facilitators?

For control over the stack and risk decisions, for economics that work at very large scale, or because their vertical is one the PFaaS provider's sponsor bank will not support. Rarely because they hit a GMV milestone.

Should my platform become a payment facilitator?

Probably not. Start with a referral model or PayFac-as-a-Service and register only when the reasons for control, risk or scale are real and specific.