PayFac-as-a-Service vs. Becoming a PayFac: Revenue Share, Costs, and Support
PayFac-as-a-Service lets a software platform embed payments using a provider's infrastructure and operating framework. Becoming a registered payment facilitator means taking on a larger set of program responsibilities with an acquiring partner. The right choice depends on the payment experience you need, the economics you can capture, and the work your team is equipped to own.
The important question is what the business can actually launch, support, and grow. A higher share of payment revenue can be attractive, but it has to cover the additional people, systems, risk, and ongoing work required to earn it.
Start with the payments business you want to build
A software company can earn payment revenue through several arrangements. You might integrate merchant accounts through a processing partner, use a managed payment-facilitation program, or operate as a registered PayFac. Each can support an embedded experience. The commercial agreement and implementation determine the details.
My starting point is practical: who sets merchant pricing, who helps the merchant get approved, who resolves a missing deposit, and who can explain the platform's payment income? If the answers are unclear, the proposal is not finished.
An independent software vendor, or ISV, describes the software business. It does not describe a mutually exclusive alternative to being a PayFac. An ISV can use different payment models as its business changes. Our payment facilitator guide explains the underlying terminology.
Compare the models by control and operating work
Do not assume that every provider using the same label offers the same arrangement. Two PFaaS proposals can differ in merchant pricing authority, loss exposure, reserve requirements, support, and the costs deducted before a revenue share is applied.
Also separate the experience you control from the infrastructure you operate. Branded onboarding and an embedded checkout do not, by themselves, establish who is the registered PayFac or who is accountable for underwriting and settlement.
What changes when you become a registered PayFac?
Visa's Payment Facilitator Model identifies the acquirer, payment facilitator, and sponsored merchant as distinct participants. It describes acquiring sponsorship, merchant contracting, monitoring, and settlement responsibilities. The actual program must follow the relevant network rules and agreements.
For a software leadership team, the implication is straightforward: registration is part of a larger operating commitment. Plan the policies, systems, staffing, controls, and financial resources required to run the program after launch.
- Merchant onboarding and risk: establish how applications are reviewed, what additional information can be required, and how activity is monitored after approval.
- Money movement and reporting: define how transactions, fees, reserves, adjustments, and merchant deposits are recorded and reconciled.
- Merchant support: equip people to answer questions about payment failures, funding, refunds, and disputes.
- Program governance: maintain an accountable owner, documented procedures, and a clear escalation path with the acquiring and processing partners.
A managed model can delegate substantial work. It still needs a written responsibility map. The platform continues to make product, customer-experience, and commercial decisions, and its obligations depend on the specific arrangement.
Ask who does the work before comparing the price
For each workstream, record three things: the accountable organization, the people performing the task, and the escalation contact. A logo on the merchant portal is not a substitute for that map.
Walk through one merchant's application, first payment, first payout, refund, and support request. The handoffs become much easier to evaluate when you can see the complete workflow. Ask the provider to demonstrate the proposed setup rather than explaining only the API.
Calculate the complete economics
Begin with the volume the platform can realistically capture. Total merchant sales, payments eligible for the offering, and payments actually processed through it are different numbers. Merchant adoption and payment mix can change the outcome more than a small difference in the quoted processor markup.
Then reconcile the money. Start with merchant fees, identify network and provider costs, and apply the agreed revenue-share calculation to the correct base. A percentage without a defined base is not enough to evaluate the deal.
- Implementation: integration, testing, merchant migration, device changes, and internal project time.
- Recurring provider costs: platform, gateway, transaction, active-account, payout, reporting, and other applicable charges.
- Internal operations: support, finance, risk, compliance, security, and program leadership.
- Financial exposure: expected losses and their allocation, insurance where relevant, and the financing cost of required capital or restricted cash.
- Commercial commitments: minimums, volume tiers, term, renewal, termination, and transition assistance.
Keep reserves separate from expenses. Cash held in reserve affects liquidity; it is not automatically a permanent cost. Likewise, payment income, contribution after specified costs, and accounting revenue are different measures. Have finance establish consistent definitions and the appropriate reporting treatment.
How software platforms make money from payments
Embedded payments monetization starts with the fees paid for payment services and the economics your agreement lets the platform retain. Common structures include a share of defined net processing income, a markup over a specified provider cost, or a platform fee. The percentage on a proposal is only useful once you know the calculation beneath it.
A practical revenue-share waterfall: eligible merchant fees collected, minus the explicitly agreed deductions, equals the shareable amount. Apply the platform's contractual share, then subtract the platform's own operating costs to assess contribution. Some agreements calculate the share differently; reconcile the exact formula to a sample residual report before comparing offers.
A buy rate is the provider cost charged under your arrangement. A merchant sell rate is the price offered to the merchant. The gap between them is not automatically your income: interchange, assessments, per-transaction charges, payment-method costs, and other agreed deductions may apply. Identify which charges are included in the quoted rate and which are additional.
A bigger revenue-share percentage can still pay less
The following monthly comparison is entirely hypothetical. Both offers process $10 million and collect $280,000 in eligible merchant fees. It isolates the effect of the deductions and revenue-share base; it does not quote market pricing or describe a customer.
Offer B advertises the higher share but produces less platform income in this example. Ask why its deductions differ, whether both offers include the same services, and whether either moves work onto your team. Re-run both proposals using the same merchant mix, transaction count, refund assumptions, and captured volume.
Model ACH separately from cards
A home-services software platform may collect large invoices through both cards and ACH. Different ticket sizes, merchant pricing exceptions, ACH fee caps, provider costs, and returns can produce different economics. Calculate the fee on each transaction or a representative distribution. Multiplying all ACH volume by a headline percentage can overstate income when a cap applies.
For example, an invented ACH price of 0.8% capped at $12 produces a $12 merchant fee on a $5,000 payment, before any provider charges or revenue share. It does not produce $40. This illustrates the cap mechanism only; it is not a recommended price or a customer term.
How to negotiate payment costs and revenue share
Bring evidence to the negotiation: recent processing and residual reports, the actual merchant fee schedules, payment-method and ticket-size mix, application and activation counts, and the support scope you need. Distinguish historical results from assumptions about merchants who have not activated yet.
- Define the revenue pool. List included and excluded merchant fee categories. Clarify how refunds, chargebacks, monthly fees, adjustments, and credits affect the calculation.
- Make the cost schedule explicit. Separate pass-through network costs from provider markup and other charges. Specify ACH, gateway, active-account, payout, minimum, and implementation costs where applicable.
- Test a sample month. Ask the provider to calculate your share from agreed sample activity. Finance should be able to reproduce the result and identify every deduction.
- Price the work as well as the processing. Name the owner for merchant outreach, application assistance, training, funding questions, support escalation, and reconciliation.
- Negotiate growth and change. Discuss volume tiers, rate-review triggers, merchant pricing authority, notice of increases, minimums, renewal, termination, and transition assistance. Base commitments on a realistic activation plan.
Request three usable documents: a complete cost schedule, a revenue-share calculation with sample reporting, and a responsibility schedule. A polished forecast without those documents leaves too much of the business undefined. Your legal and finance teams should review the final agreement and accounting treatment.
What our home-services software work taught us
In our work with a home-services software business, transaction-volume reports were not enough to evaluate monetization. Our team requested the underlying fee components, merchant statements, and residual reporting, and investigated how card and ACH pricing flowed through the economics. That is the discipline a useful comparison requires. A dashboard total cannot explain a revenue share by itself.
The operating plan mattered too: helping pending merchants complete onboarding, getting approved merchants to their first payment, equipping sales to explain the payment offering, and supporting merchants afterward. Those are specific jobs for a payments team. The point is the method, not a claimed customer outcome; no customer figures or negotiated terms are disclosed here.
When does taking more in-house make financial sense?
Compare the additional net spread with the additional cost of operating the model. Use the same merchant cohort, volume, payment methods, transaction counts, and service scope in both alternatives. Include the ramp before reaching steady-state volume.
Illustrative example: if a model adds $200,000 in annual operating costs and improves net spread by 20 basis points, $100 million in annual captured volume covers that additional recurring cost. One basis point is 0.01 percentage point. This calculation excludes setup, adoption ramp, capital costs, and unexpected losses; it is not a universal PayFac threshold or a Swipesum quote.
The calculator is a starting point for a more complete forecast. Test lower captured volume, slower merchant migration, and higher support needs. A model that looks attractive only under the most optimistic assumptions deserves a closer review.
For a deeper discussion of the fee waterfall and merchant pricing, read our embedded-payments pricing guide. If adoption is the missing input, use our guide to growing active payment volume.
Get these answers in writing
A strong partner should be able to explain how the arrangement works in an ordinary month and when something goes wrong. Before signing, ask:
- Who can change merchant pricing, and what notice or approval is required?
- What costs are deducted before the platform's share is calculated? Can finance reconcile that calculation?
- Who bears losses, negative balances, disputes, and reserves under the proposed program?
- What support is included, who serves the merchant, and how are urgent issues escalated?
- What data and payment credentials can be transferred, through which process, and at what cost?
- What happens if volume grows slowly or the platform wants to change providers?
Review the commercial and technical documents together. A favorable headline fee can be offset by a minimum commitment, unsupported workflow, or operating task your team did not budget for. Obtain qualified advice on the specific legal and accounting questions rather than treating a model comparison as a contract review.
Where Swipesum Connect fits
Swipesum Connect combines embedded-payment infrastructure with the team supporting implementation, provider operations, economics, and ongoing performance. The opportunity is a payment program your software team can put to work and your business can keep improving.
Our team can help review provider pricing and revenue-share proposals, reconcile the economics to available reports, coordinate implementation, and define the merchant onboarding and support work. Pair that expertise with Connect’s payment infrastructure, reporting, and provider operations. Agree the specific service scope, owners, and deliverables for your program so the business plan has people behind it.
Swipesum earned a place on the Inc. 5000 in 2023, 2024, and 2025. Our offering brings payment products and experienced people together. When you evaluate Connect, evaluate both: what the technology enables and how the team helps you operate it.
PayFac model questions
Do I need to become a PayFac to earn payment revenue?
No. Software platforms can participate in payment economics through partner and managed arrangements. Compare the proposed merchant experience, commercial terms, and responsibilities before choosing a structure.
Is PayFac-as-a-Service the same as becoming a registered PayFac?
No. PFaaS is a service model that uses a provider's framework. Operating as a registered PayFac involves a different set of program duties and acquiring relationships. Confirm the registered entities and responsibility allocation in the actual agreement.
Which model has the highest margin?
There is no useful answer without the cost base and captured volume. Compare contribution after the provider charges, losses, staffing, systems, and other operating costs relevant to each model.
Does using a managed model remove all risk and compliance work?
No. It can delegate substantial responsibilities, but the platform's remaining obligations, financial exposure, and security work depend on its integration and agreement.
How should we evaluate moving to a different model later?
Review data portability, merchant agreements, billing dependencies, devices, minimum commitments, and operating capabilities before the move becomes urgent. Our platform payments migration guide provides a practical checklist.
Build the payments business your platform is ready to run
You do not need a perfect forecast to start the conversation. Bring your merchant count, eligible payment volume, software requirements, current provider proposal, and the people available to run the program. Swipesum can help connect those inputs to a workable payment model and implementation scope.
Sources and scope: Visa's Payment Facilitator Model is the network reference linked above. Product descriptions refer to Swipesum's current Connect offering. All calculator defaults and financial examples are hypothetical; specific program terms determine actual responsibilities and economics.
