Merchant of Record vs. PayFac vs. Payment Processor: Which Model Fits Your Product

It’s difficult to directly compare a merchant of record vs. a PayFac vs. a payment processor because these aren't competing options.

Instead, they're different layers of the same stack.

A processor moves money. A PayFac sponsors and underwrites the businesses that sell. A merchant of record is the legal seller. With a processor or a PayFac, you are still going to be the merchant of record by default.

Let’s look at everything you need to know about these three models from an engineering point of view, so you can have a better understanding of what to discuss with legal counsel before including it in your product.

At Trio, we have fintech engineers with production experience in these sorts of issues. They can not only help you identify gaps in your architecture, but also implement the solutions without sacrificing security or compliance.

View capabilities.

Merchant of Record, PayFac, and Payment Processors: Layers of the Same Stack

A payment processor moves money between accounts. It talks to the card networks and the banks, authorizes a card, and settles the funds.

A payment facilitator, or PayFac, is something else entirely, and occupies a sponsorship position.

In other words, the PayFac holds a master merchant account and underwrites the businesses that sell beneath it, its sub-merchants.

A merchant of record is a legal role that wraps the whole thing. This is the entity the customer actually buys from, the name on the card statement, and the party that owes the tax and answers the chargeback.

You need all three of these layers in your tech stack at the same time.

For example, when you plug in a large platform like Stripe, you get a gateway, a processor relationship, and PayFac-style onboarding bundled into one product. What you do not get is someone to take the merchant of record role off your hands.

That means you are still going to be responsible for the tax registration, the VAT and GST remittance across the places you sell, and the chargeback liability.

If you sell your own product, the question is whether you stay the merchant of record or hand that role to a third party built to hold it.

It gets a little more difficult if you run a platform whose customers sell, like an e-commerce site. The question then becomes, do you become a PayFac yourself, rent the model through PayFac-as-a-service, or stay out of the payment flow entirely and refer your customers elsewhere?

What Each Model Actually Makes You Responsible For

Liability is where the three layers separate cleanly, so start there before touching cost. The table sorts the responsibilities that actually move a decision.

Tax is probably one of the first factors you should consider, and the one we see forgotten the most. You need to remember that a PayFac does not calculate, file, or remit anyone's sales tax. Sub-merchants stay the merchant of record for their own sales and carry their own obligations wherever they have nexus.

If you are selling your own product through a PSP, VAT and GST registration across every jurisdiction you sell into belongs to you, which is usually why tax software shows up as a separate line item next to a PSP, and why a third-party merchant of record's fee stops looking expensive once you price the compliance work it absorbs.

The second factor we recommend you consider is PayFac chargeback exposure. A sub-merchant might own its disputes, but the acquirer looks to you.

Any contract that you have with an acquirer is probably going to hold you responsible, so if a sub-merchant disappears owing chargebacks you cannot recover, that loss lands on the PayFac.

In other words, don’t think that you are just renting rails. Instead, you are standing behind a portfolio of businesses you approved. That’s a very different risk profile you need to weigh.

Platforms sometimes try to run both roles at once, acting as merchant of record for their sub-merchants' sales while also operating as a PayFac. Trying to do that creates very complex compliance exposure.

What Each Model Costs to Build

Realistically, liability and fees are only half the decision. The other half is what each model asks you to build and, more importantly, to staff.

Third-party merchant of record: the smallest build

All you need to do is integrate a checkout and listen to a webhook. The merchant of record handles tax, disputes, compliance, and much of your PCI scope.

What you still take into account in your build is entitlement and provisioning logic driven off their events, subscription state mirrored in your own system so your product is not blind between webhooks, and reconciliation between their payout reports and your revenue records.

The primary cost you need to think about here is the customer relationship and the data. Their name sits on the statement, and you receive their reporting rather than raw settlement data, which narrows what you can analyze and weakens your position in any future renegotiation.

We often recommend this model when people are trying to sell into many tax jurisdictions, if their team is small, and speed to market matters more than owning every layer.

Digital products and B2C SaaS land here often.

Direct processor: the middle build

This option is great because you get your own merchant account, your own MID, and your own name on the statement, which buys you the best rates and full control of your data.

In exchange, you need to build the integration itself, reconciliation against settlement files, a dispute-handling workflow, and a tax solution, which in practice means a third-party tax engine plus the registrations behind it.

We often find that teams underestimate that last piece in particular. The code to call a tax API is small, but the registration and filing footprint it implies is not.

When you reach several processors, the architecture question shifts to integrating payment processors and, above that, payment orchestration, both downstream of this decision.

This model fits when you sell your own product, your tax footprint is manageable, and your volume justifies negotiating rates directly.

If the customer relationship is strategically central, the direct processor route plus a bought tax engine keeps the statement and the data in your name, which is usually worth the extra operational load.

Becoming a PayFac: the largest build by a wide margin

A sponsoring acquirer has to underwrite and register you if you want to become a PayFac. The entire process could take 12 to 24 months, with infrastructure investment well into six figures before a single sub-merchant is live.

What you are actually building and running:

• Sub-merchant onboarding: KYB and KYC on the businesses and their beneficial owners, document collection and verification, and sanctions screening. This is a build and a queue that never empties.
• Underwriting: A risk decision on every applicant, backed by a written policy, plus a review path for the edge cases the policy does not cleanly cover.
• Ongoing risk monitoring: Per-sub-merchant transaction monitoring, velocity and chargeback-ratio thresholds, and an intervention process for when a sub-merchant's behavior drifts from what you approved.
• Funds flow and a sub-merchant ledger: Balances, holds, reserves, split payments, and payout scheduling. This has to be a real double-entry ledger.
• Payout infrastructure: Timing, failures, retries, and the reconciliation of every one of them.
• Reporting obligations: including 1099-K style reporting where it applies.
• Broad PCI scope: because you now sit in the card-data path for a whole portfolio rather than a single store.

PayFac-as-a-service: the middle path most platforms actually want

PayFac-as-a-service providers give you the PayFac economics and a native, embedded onboarding experience while they keep the sponsorship, the underwriting, and much of the compliance burden.

This is a great option because you collect a revenue share on transactions and get a fast, in-product onboarding flow for your customers, without registering as a facilitator or standing up a risk function of your own.

For most platforms, most of the time, this is the right answer.

Full PayFac registration doesn’t really make sense unless you are dealing with volumes where the economics of owning the risk function outright clearly beat renting it, because at that scale you are paying the revenue share on enough transactions that the permanent operations headcount pays for itself.

How to Decide

If you sell your own product:

1. Are you selling into many tax jurisdictions with a small team to manage them? Lean third-party merchant of record. The tax burden alone usually carries the argument.
2. Mostly domestic, or a tax footprint you can manage? Lean direct processor. You keep better economics, the statement, and the data.
3. Is the customer relationship strategically critical either way? Lean direct processor, and buy a tax engine to cover the compliance gap rather than surrendering the relationship to a third party.

If you run a platform whose customers sell:

1. Do you want payments to be a revenue line at all? If not, refer customers out and stay clear of the flow.
2. Yes, but you do not want to run a risk function? PayFac-as-a-service.
3. Yes, at real volume, and you want the full spread? Full PayFac. Budget the operations headcount and put the sponsorship timeline in your plan.

These models are reversible, but not cheaply. Moving from a third-party merchant of record to direct processing means re-establishing the customer relationship and rebuilding tax compliance from scratch. Moving from PayFac-as-a-service to full facilitation means standing up the underwriting and risk function you had been renting.

Decide with the next two years in view rather than the next quarter, and staff the decision.

At Trio, we place the payment engineers and fintech developers who build and run whichever one you choose, from a checkout integration to a full sub-merchant platform.

If you are sizing the team behind one of these paths, we may be able to help.

Request a consult.