Embedded payments for software companies.

"Embedded payments" gets used to describe four or five different things. For an independent software vendor — a SaaS platform whose customers are the merchants — it means three specific commitments: payment acceptance happens inside the platform UI rather than via a redirect, payment data lives in the platform's system of record, and the ISV controls the merchant experience end-to-end. That is the bar; anything below it is a referral relationship dressed up in modern terminology.

Getting to that bar requires a gateway that ships the primitives an ISV actually integrates against — REST endpoints, predictable webhook shapes, idempotency, a hosted-field SDK, a tokenized vault — and a partner model that does not put the gateway in conflict with the ISV when the platform grows. Fluid Pay was built for ISV embedding from the start, which is why the API is REST-first, the vault is portable, the component library exists, and partner-only is structural rather than contractual.

The integration surface an ISV cares about is narrower than the marketing surface most gateways present. In practice it is six primitives.

REST endpoints with consistent semantics. Authorizations, captures, sales, refunds, voids, customer creates, payment-method tokenization, subscription create/update/cancel. Same request shape, same response shape, same error model across every endpoint. Anything else slows every release.

Webhooks with idempotency keys. Payment state changes pushed to your endpoint with a stable event ID so retries do not double-fire downstream logic. The webhook payload includes enough context to act on without a follow-up API call.

Hosted fields and tokenization. Card data captured in iframes hosted by the gateway, returned to your application as a token. The PAN never touches your servers, your PCI scope drops to SAQ-A, and your engineering team never has to think about card-data security as a feature of their week.

A vault that survives migration. Saved payment methods stored as tokens in a vault you can export. The cost of leaving any payments provider is in the vault, not the API surface — the API can be re-implemented in a sprint; rebuilding a vault from scratch can mean asking every customer to re-enter their card.

A component library for the parts that should not be rebuilt. Hosted checkout, hosted payment page, recurring subscription management UI, dispute response UI. The ISV ships their product faster when the payment-specific UI work is not on their roadmap.

A sandbox you can hit in 60 seconds. The shortest path from "let me evaluate this" to "I have a working integration in dev" is a major filter for ISV decisions. Our sandbox runs without a signed contract — see the developer docs.

The economic question every ISV evaluating embedded payments has to answer is: "what does the gateway take, and what do I keep?" Most gateway and PayFac platforms have layered, opaque answers to that question — usually because they have an interest in the answer being unclear.

Ours is intentionally simple. You set the rate to the merchant. We take a per-transaction processing margin that is published, fixed, and visible in your partner portal. You keep the residual spread between what you charge the merchant and what we cost. There is no per-merchant license fee, no platform fee that grows as your merchant count grows, no "growth charge" that kicks in once you cross volume tiers.

This matters because the unit economics of embedded payments compound. A SaaS platform with thousands of merchants ends up with a payments revenue line larger than its subscription line within a few years of turning embedded payments on. That payments revenue is structurally higher-margin than SaaS revenue once it is running. The gateway you pick when you have 50 merchants is the gateway that defines your margins when you have 50,000.

Most ISV stories start online. They almost never stay online.

Field-service platforms add tap-to-pay on a phone. Healthcare practice management adds front-desk terminals. Marketplace platforms add in-person pickup. The day the first customer asks for card-present is the day the embedded-payments architecture is tested for real, because "online-only" gateways either do not have a card-present story or treat hardware as a separate product with a separate vault and separate reporting.

Fluid Pay is one platform across both. EMV, contactless and tap-to-pay run against the same vault that holds the online payment methods. A customer who paid online last week and walks in this week is the same customer in the same record on the same reporting surface. The ISV does not change vendors when card-present matters; the toggle is a configuration, not a re-integration.

Most ISV embedded-payments implementations fall into one of four patterns. Knowing which one fits before integration starts is worth more than any individual technical decision.

Book-of-record SaaS. Practice management, field service, scheduling, billing software. The platform creates invoices and the customer pays them inside the platform. Recurring billing is usually involved. The right embed is hosted fields + the recurring engine + customer vault + account updater. The ISV does very little payment-UI work.

Marketplace. A platform with multiple end-merchants accepting payments through the platform. Each end-merchant has their own MID, their own funding, their own reporting. The right embed is hosted fields + branded hosted payment pages + per-merchant configuration + portfolio-level reporting for the ISV.

Field-service. A platform whose users are mobile — a technician at a customer site, a contractor on a job. Card-present matters from day one and tap-to-pay on a phone is often the first hardware. The right embed is the API + a mobile SDK + the supported tap-to-pay terminal stack.

Vertical workflow with embedded billing. The platform owns a workflow — clinical, legal, fitness, education — that culminates in a billable event. Embedded payments are the close of that workflow. The right embed is the API + recurring billing + dunning + account updater, with the platform owning the customer relationship and the gateway invisible.

Most ISVs evaluating Fluid Pay have an existing payments integration they are not happy with. The migration question is usually the deciding question.

Two specifics matter for ISV migration. First, the vault: how much friction is there in moving the payment methods you have already collected? Fluid Pay can ingest tokenized vault data from most major providers without forcing customer re-entry. The vault you migrate in is the vault you continue to run; nothing fails on day one because a card-on-file did not come over.

Second, the integration surface: how much code has to change? Our Gateway Emulator speaks the dialects of the most common gateways ISVs are migrating off — including the legacy AIM/SIM/CIM patterns. For platforms whose integration is well-abstracted, the migration is a configuration change. For platforms whose integration is messier, the rewrite is contained and recoverable rather than a multi-quarter project.

The pattern we see most often is a Stripe migration: the ISV outgrew the unit economics, hit a roadblock with Stripe Connect's constraints, or wanted to own the merchant relationship in a way Stripe's model does not allow. The vault comes across, the integration is rewritten on top of our REST API in two to four weeks, and the partner economics flip from net-paying-Stripe to net-collecting-residuals inside the first quarter.

For an ISV, the compliance question is less "are we compliant?" and more "how much of our engineering attention does compliance take per year?" The answer scales directly with how much card data the application touches.

Hosted fields are the first lever. The card number is entered in an iframe served by Fluid Pay; the data never reaches the ISV's servers; the ISV receives a token that represents the card. That setup keeps the ISV under SAQ-A (the lowest-scope PCI questionnaire) for most of the application — usually a few hours of attention per quarter instead of a multi-day audit prep cycle.

Token-first integration is the second lever. The Fluid Pay vault stores the PAN behind a stable platform token; your application never holds, transmits or logs cardholder data. The token is what flows through your codebase, your CRM, your reporting and your support tooling — and the token is what becomes the input to every subsequent charge, refund, recurring schedule or dispute response.

The third lever is vault portability. A vault that is hard to export is a compliance liability disguised as a feature; the lock-in is the risk. Our vault is exportable by design — not because we expect partners to leave, but because non-portable vaults make migration projects into compliance projects, and we do not want our partners stuck with that pattern.