Embedded Payments

Embedded payments are one part of embedded finance. The wider field also includes accounts, credit and insurance offered through a nonfinancial product. Payment integration concerns accepting money and delivering it to the recipient. A platform can provide this function without adding a loan or issuing its own card.

The platform experience and the underlying payment method are separate choices. Cards and bank transfers can both support embedded payments. Open banking can provide a route to initiating a bank payment, while payment orchestration concerns routing requests between providers. These technologies can work together within one product.

A software platform can integrate a provider's payment components into its own interface. The provider processes the transaction; the platform connects the result to the customer's purchase. Ready-made components and customized integrations allow different levels of control over that experience.

The operating model also determines who onboards merchants and handles payment risk. A payment facilitator manages submerchants under its acquiring arrangement. A platform using a provider-operated payment facilitation model can integrate those functions through APIs. Contracts still need to allocate responsibility for complaints and losses. A technical integration alone does not settle those questions.

A marketplace payment may belong partly to a seller and partly to the platform. The system must record the seller's share and any platform commission separately. Split instructions allocate payments, refunds and chargebacks to balance accounts. Those allocations are accounting records within the provider's platform; a payout is a later movement to the recipient's bank account.

The payout schedule affects when a seller can use the money. A refund after payout may require recovery from a seller's balance or a reserve, depending on the contract. Before launch, teams should define the treatment of partial refunds and the party responsible when a seller cannot cover a chargeback. Payment acceptance and seller payout need their own status information.

Embedded payments for SaaS let a business collect money within the software used for its daily work. Industry-specific software and marketplaces use this model for invoicing or customer purchases. A business can associate the incoming payment with the underlying service without entering the same reference in another tool.

Subscriptions add a different requirement: the software needs to handle a renewal that succeeds or fails after the customer has left the application. B2B payments may need invoice references and approval steps before the transfer. Travel platforms may separate an initial deposit from a later balance. The product's commercial rules determine the payment workflow, including what happens when an order changes.

A successful checkout screen is not the final accounting record. Some payment methods confirm later, and a completed purchase can still receive a refund or dispute. Signed webhook notifications communicate asynchronous payment events. The platform uses those events to update the order and its financial records.

A reconciliation process connects each purchase to its payment reference and payout. Teams should retain the gross amount, deducted fees and any adjustments so that the final bank credit can be explained. Duplicate notifications and delayed responses need tests before launch. Otherwise a customer might see an unpaid invoice even though the provider has already received the money.

Embedded payments do not remove authentication requirements. In the EU, strong customer authentication rules and their exemptions affect electronic payments. A bank may require the customer to confirm a transaction even when checkout is integrated into the platform. The software must support that step and return the customer to the correct order.

Card acceptance also requires attention to PCI DSS. Provider-hosted payment fields can change the assessment scope, but the merchant website remains within scope even when eligible for SAQ A. Access controls and the security of the integration remain part of operating the service.

In Germany, commercial provision of payment services requires authorization under section 10 of the Payment Services Supervision Act, subject to the law's scope and exceptions (in German). A software platform's classification depends on its actual role in the payment chain. Working with an authorized provider is a starting point for that assessment, not a blanket exemption.

The operating agreement should identify the regulated provider and the party contracting with each merchant. Teams also need to establish who verifies recipients and responds when payment data changes. These arrangements connect embedded payments with banking as a service and with the risk management of outsourced financial services.

The suitable integration depends on the platform's fund flows and the countries where its customers operate. A single merchant collecting its own invoices has different needs from a marketplace paying many sellers. Compare supported payment methods and payout currencies before comparing interface features. Test the full lifecycle, including a failed payment and a refund after payout.

The economics also need a complete calculation. Payment revenue can add to software subscription income, but processing fees and operational work affect the margin. Ask which fees apply to disputes and unsuccessful payouts. The agreement should also address exporting records and changing providers, so that future product decisions do not depend on an undocumented payment setup.