Embedded Payments

Checkout, collections and payouts integrated into customer journeys

Three different payment jobs

Embedded payments integrate paying, collecting or disbursing funds into a platform journey. Checkout takes a customer's payment; recurring collections charge under an applicable agreement or mandate; payouts transfer value to merchants, workers or other recipients. A single button can hide these distinct processes and their different rights and failure states.

Identify the payee, payment-service providers, merchant arrangement and funds flow. A marketplace may act as merchant of record, payment facilitator, distributor or another permitted role. Contractual liability and customer recourse depend on the actual arrangement and scheme; they do not follow a universal rule that the visible platform holds every obligation.

From instruction to reconciled outcome

Separate authorisation or initiation, capture where relevant, clearing, settlement, account posting and recipient availability. Not every rail uses the same sequence. A card approval is not final settlement; an account-to-account initiation response is not unconditional evidence of beneficiary credit.

An embedded payment connects a platform instruction to provider processing, financial effects and reconciliation.

Join platform order IDs to provider and rail references. Handle duplicate callbacks, delayed events and unknown outcomes using explicit state transitions. Retrying after a timeout should preserve the instruction identity and enquire where needed rather than create another customer debit.

Collections and permission

Specify who may collect, the relevant authority, frequency or triggering event and customer information. Stored-card arrangements, direct-debit mandates and recurring bank-payment permissions follow different rules. Access to a card or account identifier alone is not unlimited permission to charge.

Enforce cancellation and changes through the actual collection systems. Distinguish stopping future charges from refunding completed payments. Failed collections need appropriate retry, notice and support behaviour; a new reference must not conceal repeated collection of one obligation.

Payouts, fees and balances

Explain gross sales, fees, refunds, disputes, reserves and net payable amounts according to the arrangement. A scheduled payout is not money already received. If funds are held before payout, assess the relevant legal structure and protection rather than automatically describing the platform balance as a bank deposit.

Refunds, reversals, returns and chargebacks are distinct events. Their availability, timelines and liability depend on rail, law and contract. Do not promise every account-to-account payment is unrecoverable or every card payment is fully protected against every dispute.

Worked example: an unknown checkout result

In this fictional marketplace, a checkout response times out after the provider has accepted the payment. The order stays unconfirmed while the platform enquires using the original reference. A later callback confirms the same payment and does not create a second debit.

The customer later returns part of the purchase. The refund links to the original order and payment, adjusts the seller's payable record and is reconciled to its actual financial effect. Recording a merchant refund request alone would not prove the customer's funds were returned.

Security and operating control

Protect payment credentials, callbacks, API access and privileged payout changes. Tokenisation or hosted processing can reduce exposure, but assess the actual scope. The PCI Security Standards Council outsourcing FAQ explains that outsourcing processing does not remove a merchant's responsibility to ensure account data is protected by the provider.

Monitor unresolved states, duplicate effects, aged payouts, unmatched settlement, complaint themes and recovery cases. Rehearse provider outages and reconciliation without the normal platform dashboard. Technical uptime and matched customer money are separate measures.

Takeaway

Embedded payments require clear funds flow, permission and state semantics. Reconciliation and controlled exception handling keep the commerce record, provider record and customer outcome connected.

Continue to Embedded Lending.