What does "embedded payments" actually mean for a software platform?
Embedded payments means a software platform's customers can accept payments directly inside that platform's product, rather than being sent to a separate payments provider's dashboard or checkout page. For a vertical SaaS platform, this typically looks like a merchant onboarding for payment acceptance without leaving the software they already use daily, transacting through it, and seeing reporting alongside the rest of their business data.
The appeal is straightforward: payments become part of the product experience instead of a separate vendor relationship, and the platform earns revenue participation on payment volume it would otherwise have no stake in.
What are the real architectural decisions an ISV has to make?
A few decisions determine most of what embedding payments actually costs in engineering time and ongoing operational risk:
- Underwriting model — does every customer get individually underwritten and approved as its own merchant, or does the platform aggregate customers under one master merchant account?
- Credential handling — does the platform's own systems ever touch raw payment card data, or does payment information flow through a tokenized layer that keeps raw card data out of the platform's environment entirely?
- Onboarding UX ownership — is merchant onboarding built and maintained by the platform itself, or does it use a hosted or embeddable onboarding flow from a payments partner?
- Rail and method coverage — does the integration only cover card payments, or does it also need to support bank rails and alternative payment methods as customer expectations grow?
Each of these has real, lasting consequences — the underwriting model in particular is the one most likely to determine how much operational risk the platform is actually carrying on behalf of its customers.
Why does the underwriting model matter more than it initially seems?
A platform that aggregates customers under one master merchant account (the classic PayFac aggregation model) can onboard customers faster, because there's no individual underwriting step for each one. The tradeoff is that every sub-merchant under that master account shares exposure to the aggregate's overall risk profile — an audit, a reserve requirement, or a freeze triggered by the master account's overall activity can affect a specific customer's ability to process, even if that customer individually did nothing wrong.
A platform that instead routes customers through individual underwriting — typically via a retail ISO partnership, with an FSP and sponsor bank behind it — accepts a slower onboarding step in exchange for each customer holding a real, independently underwritten merchant account, stable from its first transaction rather than subject to the aggregate's periodic review.
Neither model is universally correct — the right choice depends on the platform's customer base, transaction profile, and how much operational risk it's comfortable holding on its customers' behalf.
What should a platform's own engineering team actually own?
The strongest embedded payments implementations tend to draw a clear line: the platform owns the experience — how onboarding, payment acceptance, and reporting appear inside its product — without owning the infrastructure underneath it — underwriting, card network connectivity, settlement, and compliance. Building that infrastructure independently means becoming, functionally, a payments company: certifying with card networks, maintaining PCI-scoped systems, and staffing compliance and risk functions that have nothing to do with the platform's actual product.
A well-designed API layer lets a platform's engineers integrate against payment references and tokenized credentials — never raw card data — while the infrastructure behind those APIs handles underwriting, processing, and compliance.
What should an ISV ask a payments partner before building?
A few questions tend to reveal how much operational risk and engineering burden a given approach will actually require:
- Is each customer individually underwritten, or aggregated under a master account?
- Does the platform's own environment ever touch raw card data, or only tokenized references?
- What's actually required to add a new payment method or rail later — a new integration, or a configuration change?
- Who provides first-line technical support to end customers, and does that reduce or increase the platform's own support burden?
NGnair's approach to embedded payments is built around individual underwriting through a retail ISO partnership — every merchant an ISV originates is approved on its own, not aggregated — with a full API surface covering onboarding, orchestration, and reporting so the platform's engineering team builds against one interface rather than a payments company's worth of infrastructure.
The short version
Embedding payments well comes down to a handful of architectural decisions — underwriting model, credential handling, onboarding ownership, and rail coverage — each with real consequences for operational risk and engineering cost. The underwriting model in particular determines how much risk a platform's customers actually carry, and it's worth evaluating deliberately rather than defaulting to whichever option onboards fastest.
Traditional ISO integrations were often narrow enough that this evaluation didn't matter — there wasn't much of a real API to build against. NGnair's developer platform is built specifically so that's no longer the tradeoff: individual underwriting, with an API surface programmable enough for a real integration.
