Most vertical SaaS platforms process significant transaction volume for the businesses they serve — and collect none of the economics on those payments. A field service platform routes $3M in annual job revenue through its invoicing module. A property management platform handles $8M in rent and maintenance billing. A healthcare staffing platform processes $5M in contractor disbursements. In every case, 50–100 basis points of that GMV is available to the platform as payment facilitation revenue. Most of it goes uncaptured, not because it's inaccessible, but because the platform hasn't built the infrastructure to claim it.
This article covers the mechanics: what payment facilitation actually requires structurally, how the take-rate economics work under interchange-plus pricing, what BIN sponsorship means and why platforms need it, and what the compliance surface looks like before you process your first transaction as a payment facilitator.
What Payment Facilitation Actually Is
A payment facilitator — or PayFac — is an entity that contracts with a card network acquirer to process payments on behalf of sub-merchants. The PayFac holds the master merchant account; each business using the platform becomes a sub-merchant under that master account. The PayFac is responsible for sub-merchant onboarding (KYC/KYB), transaction routing, settlement, and chargeback management.
This is materially different from simply integrating a payment gateway. A payment gateway handles the technical transport of authorization requests. Payment facilitation means taking on the liability layer: the acquiring bank looks to the PayFac when a sub-merchant's chargeback rate spikes or when a fraudulent operator is discovered post-onboarding. That liability shift is what enables the revenue — and what creates the compliance obligations.
The distinction matters because some platform operators see "embedded payments" and assume they can achieve PayFac economics by adding a Stripe or Adyen integration under their brand. They can't. The economics of card-interchange pass-through require that the platform hold the acquiring relationship — either directly (full PayFac registration) or through a PayFac-as-a-Service provider who holds the acquiring relationship and extends it to the platform under a managed sub-PayFac arrangement.
BIN Sponsorship and the Acquiring Relationship
Every payment card transaction is routed through a Bank Identification Number (BIN) — a 6- to 8-digit prefix that identifies the issuing institution. On the acquiring side, transactions are processed under a BIN that belongs to an acquiring bank. When a platform wants to act as a PayFac, it needs a BIN sponsorship arrangement: a registered acquiring bank agrees to sponsor the platform's PayFac registration and take on the regulatory and settlement risk that comes with it.
BIN sponsorship is the first hard gate for platform payment monetization. A platform can't simply open a merchant account and start settling sub-merchants — card networks (Visa, Mastercard) require formal PayFac registration, which requires sponsorship from a registered acquirer. The acquiring bank reviews the platform's business model, the types of sub-merchants it will onboard, the transaction risk profile, and the compliance controls in place before agreeing to sponsor. This process takes weeks to months and has meaningful upfront costs.
This is why PayFac-as-a-Service exists. Providers in this space — including PayNestio — hold the acquiring relationship and BIN sponsorship themselves, and extend access to platforms through a managed sub-merchant model. The platform gets the economics and branding control of a PayFac without carrying the direct acquiring liability or absorbing the registration cost and timeline.
Interchange-Plus Pricing and Take-Rate Mechanics
Under interchange-plus pricing, the platform (or its PayFac-as-a-Service provider) passes interchange cost directly to the sub-merchant, then adds a markup — the "plus." The platform's gross take-rate is the markup over interchange. In a flat-rate model (where the sub-merchant pays a fixed percentage regardless of card type), the platform captures the spread between the flat rate and the actual interchange cost, which varies by card type and transaction type.
Interchange rates for common card-not-present transactions — the dominant type for vertical SaaS platforms that handle invoicing and remote billing — typically run in the range of 150–230 bps for consumer credit cards, lower for debit. Assessment fees (card network fees) add another 10–15 bps. A platform charging 275–300 bps all-in under a flat-rate model, where interchange averages 175 bps and assessments add 12 bps, nets roughly 88–113 bps in gross payment margin per transaction before the platform's infrastructure cost.
That's the range the 50–100 bps figure comes from — it accounts for the platform's share after paying for the PayFac-as-a-Service layer, the processing infrastructure, and the reserve holdback. Platforms at scale, with favorable transaction mix (ACH or debit-heavy), can push net take-rate above 100 bps. Platforms with high card-not-present consumer credit card mix and elevated chargeback exposure will come in lower.
Reserve Holdbacks: The Working Capital Tension
When a platform onboards sub-merchants and begins processing, the acquiring bank typically requires a reserve holdback — a percentage of gross transaction volume held in reserve to cover potential chargebacks, refunds, and fraud losses that materialize after the transaction settles. Reserve holdback arrangements vary by risk profile, but commonly range from 5% to 10% of rolling transaction volume held for 90–180 days.
For platforms, reserve requirements create a working capital tension at scale. A platform processing $1M per month in GMV at a 7% rolling reserve holds $70K in reserve against that month's volume. At $5M/month GMV, that reserve grows to $350K. The reserve is the acquiring bank's first line of protection — not the platform's capital. But understanding reserve structure matters when modeling the true cash-flow profile of a payment facilitation business.
This is not to say reserves are a penalty. They're a normal structural feature of payment facilitation, and reserves held for longer than necessary can often be renegotiated as the platform establishes a track record of clean chargeback rates (typically below 0.5% of transaction count for Visa's basic threshold). The conversation about reserve reduction is one of the first optimization levers a platform has after 12–18 months of processing history.
PCI DSS Scope and SAQ A Qualification
Payment Card Industry Data Security Standard (PCI DSS) compliance is an unavoidable requirement for any entity processing card payments. The scope of what a platform needs to comply with depends heavily on how it integrates. Platforms that use hosted payment fields — iframes or embedded JavaScript components where the card number never touches the platform's servers — can typically qualify for SAQ A (the minimal self-assessment questionnaire), which covers roughly 22 requirements rather than the 300+ in full PCI DSS Level 1 assessment.
SAQ A scope reduction is a meaningful operational consideration. It means a vertical SaaS platform doesn't need to build card data storage, tokenization, or encryption infrastructure in-house. The PayFac-as-a-Service provider handles card data capture and tokenization; the platform's integration surface is scoped out of direct card data handling. This is why the integration architecture matters — a payment form that submits directly to the platform's server before passing to the payment processor is a PCI DSS Level 2 or 3 problem, not a SAQ A problem.
What Platforms Consistently Underestimate
The compliance surface of payment facilitation is broader than most platform engineering teams expect when they first start modeling the opportunity. Sub-merchant onboarding requires identity verification (KYC for individual owners, KYB for the business entity), OFAC SDN screening, beneficial ownership collection under the FinCEN Customer Due Diligence Rule, and bank account authentication. Ongoing transaction monitoring for AML (Anti-Money Laundering) compliance is a post-onboarding obligation — the platform is responsible for detecting and reporting suspicious activity in the transaction flow across its sub-merchant portfolio.
1099-K filing is the obligation that catches the most platforms off guard. When a platform acts as the payer of record — settling funds to sub-merchants — it takes on the obligation to file Form 1099-K with the IRS for any sub-merchant exceeding the reporting threshold. The threshold changes have made this operationally significant: at $600 in annual payments, most platforms with meaningful sub-merchant volume will have a large share of their sub-merchants crossing the reporting threshold.
Understanding these obligations upfront — before the first transaction is processed — is what separates platforms that build payment monetization as a sustainable line of business from those that discover the compliance requirements after they've already made architectural commitments they need to unwind. The infrastructure layer exists precisely to handle this complexity at the platform level, so individual vertical SaaS operators aren't rebuilding it from scratch.
The decision about whether to build a direct PayFac registration or work through a PayFac-as-a-Service arrangement ultimately comes down to scale, risk tolerance, and how much of the compliance infrastructure the platform wants to own internally. At early sub-merchant counts — under a few hundred — the economics of a managed arrangement almost always win. The question of when the direct path makes sense is worth modeling carefully, and we'll cover that in more depth in a later article on the build-vs-buy threshold.
