Embedded Payments for SaaS: Earn Revenue From Customer Payments
Embedded payments let SaaS companies earn on customer transactions. Compare referral, ISV, payfac-as-a-service and payfac models by revenue and risk.
Photo: Pixabay
On this page 7 sections
- What Embedded Payments Means for a Software Company
- Four Models: Referral, ISV Partner, PayFac-as-a-Service, Full PayFac
- Payments Revenue Share Software Math: A Worked Example
- Underwriting, Risk, and Who Pays for Losses
- Onboarding Merchants Inside Your Software
- Compliance: PCI DSS, KYC, and Funds Flow
- How to Evaluate Embedded Payments Providers
Key takeaways
- Embedded payments revenue comes from two numbers multiplied together: your share of the processing margin and the number of customers who actually process through you.
- Each step from referral to full payfac raises your share of the margin and adds underwriting work and loss exposure.
- If merchant funds settle into an account you control, you carry the risk. Read the loss-liability clause before the revenue split.
- Prove adoption with an ISV or payfac-as-a-service model before weighing full payfac status.
Embedded payments means your customers take card and bank payments inside your software instead of signing up separately with a processor, and you earn a share of the processing revenue. Your earnings depend on how much of the payments business you agree to run. A referral partner earns the least and carries almost no risk. A full payment facilitator keeps the most margin and takes on the losses that come with it. For most SaaS companies, the right answer sits between those two.
What Embedded Payments Means for a Software Company
Picture salon booking software. Without embedded payments, a salon owner books appointments in your app and charges customers on a separate terminal from another processor. With embedded payments, the booking deposit and the final ticket with tip both run through your software. The salon gets one system, and you get a cut of every transaction.
Integrated payments describes software that connects to a processor where the merchant holds its own account. Embedded payments goes a step further and puts setup and onboarding inside your product. The labels matter less than two commercial questions: who approves the merchant, and who pays when a merchant's losses exceed its balance.
Every card sale carries two cost layers under any model. Interchange and network fees go to the card-issuing bank and to networks like Visa and Mastercard. Nobody in the chain negotiates those away, and our explainer on how card networks and issuing banks split control of a transaction shows where each piece goes. The processing margin is the markup the merchant pays above those costs. Your revenue is a share of that margin, plus any fee you add yourself, such as a per-transaction platform fee.
Four Models: Referral, ISV Partner, PayFac-as-a-Service, Full PayFac
Referral Partner
You send customers to a processor. The processor signs them up and underwrites them, then pays you for the referral, either once or as a recurring residual. Your software doesn't need to touch payments at all. The effort is close to zero, and adoption follows the effort: every customer who leaves your app to complete another company's application can abandon it halfway.
ISV Partner (Integrated Payments)
ISV stands for independent software vendor. In this model you build an integration with a processor or gateway. Each customer gets its own merchant account, approved by the processor and its sponsor bank, and transactions run through your software. In return, you earn a share of the processing margin on every integrated merchant.
The processor keeps the underwriting decision and the bulk of the loss exposure. Your side of the bargain is the integration work and first-line support, because a salon owner whose card reader fails will call you before calling the processor.
PayFac-as-a-Service
A payment facilitator, or payfac, signs merchants up as sub-merchants under its own master account with a sponsor bank. That structure replaces the one-application-per-merchant process with faster onboarding. With payfac as a service, a provider supplies the payfac registration and the sponsor bank relationship, plus the risk and compliance program behind them. Your software presents everything under your brand.
Your share of margin is larger than an ISV's, and many providers let you set merchant pricing. In exchange, you own the onboarding experience and the support that comes with it. Your contract decides how much of a sub-merchant's losses also become yours.
Full Payment Facilitator
Here you become the payfac. You sign with a sponsor bank, which registers you with the card networks. Underwriting and transaction monitoring become your job, whether you build the tools or buy them. So does settlement to every sub-merchant. When a sub-merchant can't cover its chargebacks, the payfac pays them.
The whole margin above your costs is yours, and the costs are real. A full payfac needs risk and compliance staff and a large engineering build. Each sponsor bank also sets its own reserve and audit conditions, so get them in writing from every bank you talk to.
Payments Revenue Share Software Math: A Worked Example
Sales conversations focus on the revenue share percentage. Adoption moves the total far more. The example below is illustrative only. Every number in the table is an assumption chosen to show the arithmetic, not a market rate or a quote.
Assume you sell gym and martial arts studio management software. Every studio that processes through you produces the same net margin after interchange and network fees. Adoption and your share change with the model.
| Model | Studios processing (of 500 customers) | Assumed annual margin per studio | Your share | Annual gross to you |
|---|---|---|---|---|
| Referral | 75 | $1,200 | 20% | $18,000 |
| ISV partner | 250 | $1,200 | 50% | $150,000 |
| PayFac-as-a-service | 300 | $1,200 | 75% | $270,000 before platform fees |
| Full payfac | 300 | $1,200 | 100% | $360,000 before operating costs |
Each row multiplies studios by margin per studio by your share. Two results stand out.
Moving from referral to an integrated model adds far more than haggling over a referral split, because adoption jumps when payments sit inside the product. The step from payfac as a service to full payfac is the smallest jump in the table. That extra margin has to pay for a risk team and compliance tooling before any of it counts as profit. Platforms become full payfacs when their volume makes that overhead a small slice of the margin, and a table like this one doesn't reach that point.
Underwriting, Risk, and Who Pays for Losses
Someone underwrites every merchant. In referral and ISV models, the processor and its sponsor bank approve or decline each one. Some of your customers will be declined or asked for more documents, and they will tell you about it. Our guide to common reasons a merchant account is denied explains where approvals stall.
In payfac models, the payfac approves sub-merchants and owns the consequences. The risk that catches software companies off guard is future delivery. A martial arts studio selling prepaid annual contracts has taken money for training it hasn't delivered. If it closes, members file chargebacks for the unused months, and the studio's account won't hold enough to cover them. Under a full payfac model, the payfac absorbs that shortfall. Under payfac as a service, the contract decides how much of it lands on you.
Recurring billing brings a quieter risk. Gyms get disputes from members who believe they cancelled. Salons get them from customers who don't recognize a no-show fee. Clear cancellation records and recognizable statement names reduce both. Our article on billing descriptors that stop "I don't recognize this" chargebacks covers the statement-name side. Under a payfac, the payfac's name appears beside the merchant's on the cardholder statement, so descriptors need more care.
Before signing, find the loss-liability clause. It says who absorbs a sub-merchant loss and whether you must fund a reserve. Check also whether the provider can debit your own payouts to cover a merchant's losses. That clause tells you more about the deal than the revenue split does.
Onboarding Merchants Inside Your Software
Onboarding decides adoption. Every screen that sends a studio owner to someone else's application costs you customers.
In an ISV model, the merchant completes and signs a processor application, prefilled with what your software already knows, and then waits for underwriting review. It's slower, and the merchant ends up with a full merchant account of its own. Payfac and payfac-as-a-service models replace that with an in-app form that collects business details, owner identity and a bank account. Low-risk merchants clear automated checks quickly, while higher-risk ones go to manual review. Fast still involves verification, as our piece on what "instant approval" merchant accounts really mean explains.
Build onboarding around how each vertical takes payment:
- Salons and spas take deposits at booking and keep cards on file for no-show fees. Card-on-file consent belongs in setup, along with a terminal that pairs with your software for tips at checkout. See storing customer cards on file and keeping them current.
- Gyms and martial arts studios run on monthly drafts. Failed-payment retries and card updater services belong in the first release, along with a timestamped record of every cancellation.
- Professional services firms bill larger invoices, where card fees add up fast. Offering ACH payment processing next to cards does more for their adoption than extra card features.
- Web design agencies want a gateway that drops into WooCommerce store builds or Shopify sites, with a revenue share on each client they place.
Compliance: PCI DSS, KYC, and Funds Flow
PCI DSS is the card industry's data security standard, and your obligations follow the card data. If your app uses the provider's hosted payment fields or hosted page, card numbers go straight to the provider and your scope stays small. Once card data passes through your servers, your scope grows sharply. A full payfac is a service provider under PCI DSS and faces much heavier validation. Ask each provider, in writing, which validation level and self-assessment questionnaire it expects from you.
KYC, or know your customer, means verifying each merchant's business and owners before it processes a sale. The processor runs these checks in referral and ISV models. In payfac models the payfac owns them, and a payfac-as-a-service provider runs them inside your onboarding flow. Sponsor banks also expect ongoing monitoring, such as flagging a merchant whose sales jump sharply or who starts selling something it never disclosed.
Funds flow is the question software companies miss most. When merchant money settles from the processor straight to each merchant's bank account, you never hold it. When it settles into an account you control and you pay merchants out, state money transmission law comes into play, along with tax information reporting on the payouts. Whether you count as a money transmitter depends on each state's law and on how the arrangement is structured. A well-built payfac-as-a-service program keeps you out of that position, and the contract language is where you confirm it. This is general information, not legal advice. Have payments counsel review any funds flow before launch.
How to Evaluate Embedded Payments Providers
Ask every provider the same questions so the answers line up side by side:
- Which bank sponsors the program, and who underwrites? Get the sponsor bank's name and find out which team makes approval decisions.
- What gets shared? Ask whether the split applies to net margin after interchange and network fees or to gross volume. Then request a sample monthly report that shows the calculation merchant by merchant.
- Who absorbs losses? Ask about reserve requirements and offset rights against your payouts. Find out what happens when a sub-merchant closes with open disputes.
- Can you take your merchants with you? Portability of merchant contracts and stored card tokens decides whether switching providers later is realistic. A gym with thousands of stored member cards can't easily collect them again.
- How does a customer sign up? Ask for a live demo of a salon signing up, including what happens when its application gets flagged.
- Which payment types and hardware come with it? In-person terminals, recurring billing and ACH all matter to the verticals above, and so does support for the payment gateways you already use.
If you're early, or you want payments income without building infrastructure, MannyPay works with software companies and agencies through its agent and ISO partner program and its referral partner program. Partners receive true profit splits with no markup on buy rates, paid as monthly residuals with detailed monthly reporting. MannyPay also serves SaaS and software businesses as merchants, along with the gyms and fitness studios and salons and spas your software is built for.
Start by measuring adoption, because it decides which model pays. Count how many of your current customers already take card payments and what they pay to do it. If that share is high and your product sits where the payment happens, an integrated model is worth building. To test the numbers against your own customer base, request a free quote and ask for a processing statement analysis. A MannyPay specialist responds within one business day.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.
