Embedded payments let independent software vendors (ISVs) process payments directly inside their own platform, instead of sending merchants to a third-party gateway. This turns payments from a pass-through cost into a genuine revenue stream, while giving merchants and their customers a faster, more reliable way to pay and get paid.
For SaaS platforms competing on retention, valuation and product stickiness, embedded payments are no longer a nice-to-have. They are becoming a standard part of how software companies grow.
An ISV, or independent software vendor, is a company that builds and sells software for other businesses to use. Practice management tools, trade job scheduling apps, accounting add-ons and vertical SaaS platforms are all examples of ISVs.
Most ISVs start out focused purely on software. Payments are treated as a side function, handled by whatever gateway is quickest to integrate. As the platform matures and merchant numbers grow, that approach starts to cost the business money, data and control.
Embedded payments are payment processing capabilities built directly into a software platform, rather than routed through an external provider. The merchant using the software collects payments, issues refunds, and views transaction data without leaving the platform.
This is different from a standard payment gateway integration, where the software simply links out to a separate payment provider's checkout. With embedded payments, the ISV owns more of the payment experience and can generate revenue from every transaction processed through it.
Direct debit and card payments are the two payment types Australian ISVs most commonly embed, since together they cover one-off invoices, subscriptions and recurring billing.
Every transaction processed through an embedded payments setup can generate revenue for the ISV, typically through a margin on processing fees. This turns payments into a genuine revenue line instead of a cost the business absorbs or ignores.
Embedded payments can contribute to a higher platform valuation by adding a scalable revenue stream, increasing customer retention and deepening the platform’s role in its customers’ day-to-day operations.
When payment history, customer records and billing workflows sit within the same platform, switching providers becomes more disruptive. This can increase product stickiness and give merchants fewer operational reasons to move to another system.
Merchants and their customers complete the entire payment journey without being redirected to another site. Fewer steps, fewer external logins, and fewer redirects reduce checkout drop-off and cut down on support tickets tied to payment confusion.
Australian class-management platform PassM8 used Pinch to bring recurring payments, individual studio merchant accounts and flexible platform fees into one workflow. This shows how businesses can embed payments directly into their software to simplify payment management.
Embedded payments keep the entire payment experience, and the revenue it generates, inside the ISV's own platform.
Integrated payments connect an existing payment tool to your software. The payment processing happens in that separate tool. Your software just passes data back and forth; the user may still be redirected, and the merchant account typically belongs to the payment provider.
In short, integrated payments connect your software to a payment tool. Embedded payments make your software the payment tool.
An embedded payments API is the technical layer that makes embedded payments possible. It connects a software product to payment infrastructure, card networks, bank debit systems and merchant accounts, without the ISV building that infrastructure from scratch.
A well-built embedded payments API should cover:
The Pinch Payments API is REST-based and includes a full Postman collection. Its sandbox includes a time-travel function for simulating future payment dates, so engineering teams can test a full billing lifecycle before launch. Moving to production is a key swap, with nothing else in the integration changing.
Most ISVs building embedded payments follow a similar path as volume grows:
1. Integrate via API. Embed card and direct debit payments directly into the product.
2. Onboard merchants. Automate KYC and account activation within the platform.
3. Monetise. Apply wholesale-based fee structures to generate transaction margin.
4. Graduate to PayFac. Move to full payment facilitation and own the merchant relationship end to end.
Becoming a registered payment facilitator (PayFac) directly is a significant undertaking. It involves compliance obligations, risk management, underwriting and ongoing regulatory reporting that most software companies are not resourced to handle in-house. This is where PayFac-as-a-Service becomes relevant.
PayFac-as-a-Service enables an ISV to offer embedded payments to its merchants while the platform handles much of the merchant onboarding, risk management and compliance infrastructure. The ISV keeps the merchant relationship and a share of the payments revenue, without carrying the full regulatory burden of becoming a payment facilitator itself. Glassbox delivers this as a full PayFac-as-a-Service layer built on top of the Pinch Payments API, so an ISV can move from step one through to step four, from embedding payments to owning full payment facilitation, without switching providers or rebuilding its integration.
ISVs evaluating an embedded payments partner should weigh up:
1. API quality. Is it REST-based, with a sandbox and complete documentation, so the full payment lifecycle, including failures, can be tested before going live?
2. Payment method coverage. Does it support both card and BECS direct debit from a single integration?
3. Merchant management. Can sub-merchants be onboarded within your platform, and who holds the compliance obligation for each one?
4. Fee control. Can you set your own fee structures and create margin, or are you locked to the provider's pricing?
5. Accounting integration. Does it sync with Xero, MYOB or QuickBooks out of the box? Manual reconciliation at scale undermines the case for embedding payments at all.
6. Compliance handling. Who manages PCI, AML and KYC obligations, the platform or the provider?
7. Support. Is there a local team you can talk to, or only documentation and a ticket queue?
Pinch provides the embedded payments stack ISVs need at each stage of that path.
The Pinch Payments API covers BECS direct debit, Visa, Mastercard, Amex and international cards, with two-way accounting sync to Xero, QuickBooks and MYOB. Managed Merchants lets a platform onboard sub-merchants with their own independent merchant accounts, with automated KYC and 24-hour activation. A custom fee engine allows per-merchant pricing on wholesale rates, so the ISV can build its own margin after interchange, scheme and merchant service fees.
For ISVs ready to own the full payment experience, Pinch Glassbox is Pinch's PayFac-as-a-Service platform. It layers on top of the API with integrated KYC automation, online merchant onboarding, a custom disbursement engine, scheme-compliant reporting, and fraud detection. Glassbox is Australia's first PayFac-as-a-Service platform, approved by Australian acquirers. Pinch's payments infrastructure runs on Fiserv's global acquiring and settlement network, supporting cards, BECS direct debit and digital wallets on one platform.
If embedded payments are on your roadmap, it's worth scoping the fit before you build.