An Embedded-Payments Integration Checklist

Embedding payments means wiring a platform to accept, hold, split, and pay out money for other businesses. End to end it involves choosing an integration model, onboarding and verifying sub-merchants, designing money flow and payout timing, tokenizing card data, handling webhooks and disputes, and reconciling every cent — plus the compliance that follows once you touch custody of funds.

Most teams underestimate the second half of that sentence. Accepting a card is a solved problem; a hosted checkout does it in an afternoon. The hard part of embedded payments is everything that happens after authorization: who is liable when a sub-merchant commits fraud, when funds actually settle, how you take your cut without creating a tax mess, and whether the way you route money quietly turns you into a regulated money transmitter. This is the checklist we work through at FinWeb before a client writes a line of integration code.

Which integration model should you choose: payfac, ISO, or managed?

Pick the model that matches how much control, liability, and margin you want to own. A referral or ISO model is lowest effort and lowest control. A managed facilitator model (Stripe Connect, Adyen for Platforms) gives you most of the economics with the provider carrying the license. A registered payment facilitator gives you full control and full liability.

The distinction is not cosmetic — it decides who underwrites sub-merchants, who holds funds, and who answers to the card networks. A true payment facilitator (payfac) registers with Visa and Mastercard under a sponsoring acquirer, underwrites its own sub-merchants, and takes on settlement and compliance liability directly. A managed model — sometimes sold as “facilitator-as-a-service” — lets the provider be the registered payfac while you keep the merchant relationship and a healthy share of the revenue. For most fintechs the managed model is the right first move; you get the branded, embedded experience without an eighteen-month registration project. We unpack the two providers most teams weigh in Stripe vs. Adyen for a fintech.

Integration model	Control you hold	Compliance & liability burden	Best fit
Referral / ISO	Low — you refer, provider owns the merchant	Minimal; provider carries it	Earliest stage, no product need to touch funds
Managed facilitator (Connect, Adyen for Platforms)	Medium-high — branded flow, you set fees	Shared; provider is registered payfac	Most embedded-payments platforms
Registered payfac	Full — you underwrite and settle	Full; network registration, underwriting, funds liability	High volume, payments is the core product
Own money-transmitter license	Full custody and movement	Highest; state MTLs plus FinCEN registration	Wallets, stored balances, non-card flows

Deciding where you sit on this table is a build-vs-buy question in disguise. Our build vs. buy framework for fintech infrastructure walks through when owning the control plane is worth the liability it drags along.

How do you onboard sub-merchants and clear KYC/KYB?

Every business you pay out to has to be verified before money moves. That means Know Your Business (KYB) checks on the entity, Know Your Customer (KYC) on its beneficial owners, and enabling the specific account capabilities you need. In a managed model the provider collects and verifies this; you design the flow and decide how much friction to absorb.

Stripe’s Connect documentation is explicit that you must collect and verify defined information per connected account before capabilities like charges and payouts turn on (Stripe Connect docs). Adyen’s platform product follows the same shape through its onboarding and verification flows (Adyen for Platforms). The engineering questions that matter:

• Progressive vs. upfront collection. Take the minimum to start accepting, then request the rest before the first payout. Front-loading every field kills activation.
• Verification state as a first-class object. A connected account moves through pending, restricted, and active states. Your UI has to reflect exactly what is blocking payouts, not a generic error.
• Capability gating. Charges and payouts are separate capabilities with separate requirements. Model them independently.

If verification is a core part of your funnel, the same discipline that governs consumer onboarding applies here. See choosing a KYC vendor for how to evaluate the identity layer underneath.

How does money flow, and when do payouts settle?

Map the flow of funds before you build anything: where money lands after a charge, who holds the balance, how you split it, and when it reaches the sub-merchant. Settlement from the card networks is typically a day or two behind authorization, and payout timing to sub-merchants is a schedule you configure, not an instant event.

The critical design choice is custody. In a destination or direct-charge model, funds can settle to the connected account’s balance, and the platform never holds them. In a separate-charges-and-transfers model, funds land in your platform balance first, then you transfer to sub-merchants. That second pattern is more flexible and more dangerous: holding a balance is exactly the fact pattern that raises money-transmission questions (next section). Decide deliberately, because the flow you pick also determines who bears negative-balance risk when a refund or chargeback lands after payout.

Payout timing is a product lever, not just plumbing. Faster payouts are a selling point but expose you to more risk before funds finalize. Offer a default schedule, reserve the ability to hold funds for risky accounts, and make the timing visible in your dashboard so sub-merchants are never guessing.

Does taking payments make you a money transmitter?

Possibly — it depends on whether you take custody and control of other people’s money. If funds pass through an account you control before reaching the recipient, you may be acting as a money transmitter, which triggers FinCEN registration as a money services business and, potentially, state-by-state money-transmitter licensing. If the provider holds funds under a managed model, that exposure usually stays with them.

This is the single most expensive thing teams get wrong. Money transmission is regulated at both the federal and state level; FinCEN sets Bank Secrecy Act obligations for money services businesses (FinCEN, BSA requirements for MSBs), and states run their own licensing regimes on top. A full 50-state license program takes years and serious capital. The whole appeal of a managed facilitator model is that it lets you build a payments product without holding the funds yourself — the provider is the licensed party. If your design has money resting in a platform-controlled account, get regulatory counsel before you ship, not after. This is not advice we hand-wave; the flow-of-funds diagram is a legal document.

How do fees, revenue share, and 1099-K reporting work?

You monetize embedded payments by adding a margin on top of processing cost or taking an application fee on each transaction. Alongside the revenue comes a reporting duty: platforms that settle payments to sub-merchants are generally third-party settlement organizations and must issue Form 1099-K to those sub-merchants above the IRS threshold.

On pricing, the two common structures are a flat markup (you charge sub-merchants more than your blended cost and keep the spread) and an application fee (a fixed or percentage cut skimmed at charge time). Managed platforms support taking that fee natively so you never handle the gross funds. Model your economics against real interchange, not a headline rate — the 2026 fintech stack covers where payments margin actually sits.

On reporting, the IRS is clear that third-party settlement organizations must report payments for goods and services on Form 1099-K once a payee crosses the applicable threshold, and may issue below it (IRS, Understanding your Form 1099-K). Thresholds have shifted repeatedly in recent years, so treat the current figure as a moving target and confirm it each tax year rather than hard-coding it. Practical implications:

• Collect tax identification details during onboarding, not at year-end.
• Track gross reportable volume per sub-merchant, separate from your fees.
• Confirm whether your provider files 1099-Ks on your behalf or leaves it to you.

How do tokenization, idempotency, and webhooks keep money movement correct?

These are the three engineering primitives that separate a demo from a payments system. Tokenization keeps raw card data out of your servers so you never store a primary account number. Idempotency keys stop a retried request from charging a customer twice. Webhooks tell you about asynchronous events — settlements, disputes, payout failures — that never come back in the original API response.

On PCI scope: using hosted, tokenized card collection (Stripe Elements, Adyen Components) means card data goes directly to the provider and you handle only a token. That keeps you in the lightest self-assessment tier defined by the PCI Security Standards Council (PCI SSC) instead of the full-blown validation that touching raw card numbers demands. Never let a PAN traverse your backend if a token can do the job.

On idempotency and webhooks, the rules are non-negotiable:

• Send an idempotency key on every mutating request. Network timeouts are indistinguishable from failures; without a key, your retry is a double charge.
• Verify webhook signatures before trusting any event. An unauthenticated webhook endpoint is a way to fake payments.
• Process events idempotently and expect them out of order. The same event can arrive twice; a “payment succeeded” can land before you have finished handling “payment created.”
• Treat webhooks as the source of truth for async state, and reconcile against the provider’s reports rather than assuming delivery.

How do you handle refunds, disputes, and chargebacks?

Build these paths on day one, because they decide who loses money when a transaction goes wrong. Refunds are voluntary reversals you initiate. Disputes and chargebacks are customer-initiated reversals through the card networks, and in most platform models the sub-merchant — or you — bears the liability, plus a fee, even if you eventually win.

The mechanics you have to design for:

• Negative balances. A chargeback after a sub-merchant has been paid out can push their balance negative. Decide upfront whether you claw back from future volume, hold a reserve, or absorb the loss.
• Evidence submission. Disputes have deadlines and a structured evidence flow. Surface them to sub-merchants with enough lead time to respond.
• Reserves for risky accounts. The right to hold a rolling reserve is your main defense against a sub-merchant that disappears mid-dispute.

Liability allocation differs by model — in a registered payfac model more of it lands on you — which is one more reason the model choice at the top of this checklist propagates through everything.

What belongs on the ledgering, reconciliation, and go-live checklist?

Before launch you need a ledger that records every money movement, a reconciliation process that matches your records against the provider’s settlement reports to the cent, and a test plan that exercises the unhappy paths. Go live only when a disputed, refunded, partially paid-out transaction reconciles cleanly end to end.

A double-entry ledger is not optional for a platform moving other people’s money. Every charge, fee, refund, transfer, and payout is a pair of entries, and your balances should always reconcile against what the provider says you hold. Reconciliation runs on a schedule against provider settlement and payout reports; a break is an incident, not a rounding note.

Here is the pre-launch checklist we run:

1. Integration model confirmed and its liability documented in writing.
2. KYB/KYC onboarding verified across pending, restricted, and active states.
3. Flow of funds diagrammed and reviewed for money-transmission exposure.
4. Tokenized card collection in place; PCI scope confirmed at the lightest applicable tier.
5. Idempotency keys on all mutating calls; signed webhooks processed idempotently.
6. Refund, dispute, and chargeback paths built, including negative-balance handling.
7. Application fees / revenue share implemented and tax details collected for 1099-K.
8. Double-entry ledger reconciling against provider reports on a schedule.
9. Sandbox tests for declines, retries, disputes, delayed settlement, and payout failure.
10. Go-live runbook with rollback, monitoring, and an on-call owner.

Embedded payments is one of the few features where a shortcut in month one becomes a reconciliation nightmare in month six. If you want a team that has designed these flows before — and that owns the ledger, the compliance surface, and the sub-merchant UX together — our platform engineering practice does exactly this work. Talk to FinWeb about your integration before you commit to a model.