Last updated: October 13th, 2026
Embed the Payment Experience
This guide explains embedded payments, integration choices and the responsibilities cross-border platforms should confirm before launch. Compare API, hosted checkout and components, then use the checklist to plan payment confirmation, callbacks, refunds and testing.
Disclosure: This guide is published by HaiPay, a payments infrastructure provider. It references HaiPay's own products alongside other providers; it is educational and not financial or compliance advice. Market figures are dated and sourced; product coverage varies by market — confirm specifics for your use case.
Embedded payments build payment workflows into a software platform’s product experience. A provider supplies the processing infrastructure behind that experience. Checkout design, onboarding, settlement and payouts depend on the integration and operating model you choose.
Integrated payments connect payment processing to software workflows, such as accounting or inventory management. The terms can overlap in practice. Compare the actual checkout flow, integration depth and operating responsibilities instead of judging the implementation by its label alone.
Sources for the integrated/embedded payment comparison and redirect example: Stripe, embedded payments; Stripe, integrated payments; Stripe, embedded Checkout redirect behavior. Accessed 13 October 2026.
Embedded payments vs. integrated payments vs. embedded finance vs. BaaS
Use the distinctions below to separate the customer experience from the underlying payment and banking infrastructure. A label alone does not tell you who handles onboarding, settlement, refunds or support.
Term | What it is | Who owns the experience | Example |
|---|---|---|---|
Integrated payments | Payment processing connected to business software and its operational workflows | Depends on the provider connection and software design | Payment records synchronized with accounting or inventory software |
Embedded payments | Payment workflows built into a software product’s customer experience | The platform shapes the product experience; provider responsibilities depend on the agreed model | A platform offers checkout and payment management as part of its product |
Embedded finance | The broader category: any financial service (payments, lending, insurance, accounts) embedded into a non-financial product | The platform | A retail app offering "buy now, pay later" or insurance at checkout |
Banking-as-a-Service (BaaS) | A licensed bank exposing banking capabilities (accounts, cards, compliance) to non-banks via API, often the layer underneath embedded finance | The bank (licensed), consumed by the platform | A platform issuing branded debit cards through a partner bank |
An embedded checkout may still redirect a customer for a payment method that requires it. Confirm method-specific redirects and return behavior when designing the flow.
Sources for the integrated/embedded payment comparison and redirect example: Stripe, embedded payments; Stripe, integrated payments; Stripe, embedded Checkout redirect behavior. Accessed 13 October 2026.
This guide focuses on embedded payments. If you want to go deeper on the wider category, see our companion guides on embedded finance and Banking-as-a-Service.
A common edge case: Is Klarna embedded finance? Klarna's "buy now, pay later" option offered inside a merchant's checkout is a form of embedded finance (embedded lending, specifically) — which shows how payments, lending, and the broader category overlap in practice.
For a concise primer on how these layers relate, see Plaid's overview: What is embedded finance?
How embedded payments work
Embedded payments sit on a stack of components that most platforms consume rather than build from scratch:
- APIs and SDKs — the platform calls a provider's API, or drops in pre-built UI components, to accept and manage payments inside its own product.
- Payment rails and methods — card networks, bank transfers, real-time payment schemes, digital wallets, and local payment methods that vary by market.
- A payments provider or facilitator — the infrastructure partner that connects the platform to those rails and handles the heavy lifting of processing.
- Onboarding, KYC and AML — identity verification and anti-money-laundering checks for the platform's own users, such as merchants, sellers, or sub-accounts.

In practice, a platform integrates once and can then offer payments to its users as if it were a native feature. With HaiPay, for example, platforms can integrate payment acceptance and local payment methods through an API, Hosted Checkout, or drop-in Components — choosing the level of control and build effort that fits their product.
Embedded payments API: what to build and verify
An application programming interface (API) connects a platform’s payment workflows to a provider’s services.
The checklist below helps product and engineering teams define the integration. Confirm each function for your provider, payment methods and merchant setup. Check card-data security responsibilities before choosing a direct API flow.
Integration task | What to verify before launch |
|---|---|
Order references | Confirm how your platform order is matched to the provider’s record. Keep the references needed for payment status, refunds and reconciliation. |
Checkout and return | Choose API, hosted checkout or prebuilt user-interface components. Check which methods require a redirect and how the customer returns to your product. |
Payment confirmation | Confirm payment on your backend through a verified notification or status query. A browser return alone is not proof that payment succeeded. |
Uncertain results | After a timeout or uncertain response, check the existing order before submitting another payment. Confirm the provider’s duplicate-request rules. |
Notifications | Verify the notification signature using the provider’s documented rules. Design the handler to recognize duplicate deliveries. |
Refunds and reconciliation | Confirm supported refund operations, their final status and the references your finance team needs to reconcile them. |
Tests and launch | Test success, failure, pending results, customer abandonment, repeated notifications and refunds. Keep test and production configuration separate. |
Sources: HaiPay API rules; Stripe webhook guidance; HaiPay end-to-end testing. These sources have different provider scopes; follow the rules of the provider you integrate. Accessed 13 October 2026.
Explore payment API integration options, then review the Direct API integration guide (Chinese) for the documented order, result and notification flow.
The benefits of embedded payments
Platforms move to embedded payments for four reasons that compound:
- Payments become a revenue stream, not just a cost. Instead of pointing users to an external processor, the platform participates in the payment flow it already generates. The scale of that opportunity is why infrastructure revenue in this space is growing — in the US, Bain & Company forecast in 2022 that embedded finance platform and infrastructure revenue would more than double from $21 billion in 2021 to $51 billion by 2026 (Bain & Company). (This figure is for the broader embedded finance market, of which payments is the largest component.)
- A smoother customer experience. Users complete payment without being bounced to an unfamiliar page, which reduces drop-off and keeps the platform's brand front and center.
- Faster integration and less maintenance. Consuming a provider's API or components is far lighter than building and certifying a payment stack in-house — an effort that can otherwise take many months.
- Room to scale. As the platform grows into new segments or markets, the same integration can extend to new payment methods and geographies rather than requiring a new project each time.
To put the trajectory in context: in 2022, Bain & Company forecast that embedded finance would reach roughly 10% of all US financial transactions by 2026, with total transaction value surpassing $7 trillion (Bain & Company). Payments are the entry point into that shift for most platforms.
Embedded payments examples and companies
Embedded payments are already everywhere, even when they're invisible:
- Ride-hailing and delivery apps — you pay inside the app the moment the ride or order ends; there's no separate checkout step.
- Marketplaces — buyers pay and sellers get paid out without either party leaving the platform.
- Vertical SaaS — a scheduling tool for clinics, salons, or contractors that lets its business customers take payment inside the same software they use to run operations.
- Creator and gig platforms — payouts to creators, drivers, or freelancers handled natively.
The provider landscape spans large processors and platforms, such as Stripe, Adyen, and others, specialist facilitators, and infrastructure providers focused on specific strengths such as cross-border reach. Which one fits depends less on brand and more on the criteria below — especially if your users span multiple countries.
Embedded payments for cross-border platforms
This is where many platforms hit a wall that domestic-only guides never mention: paying with a card works fine in one market and fails in the next. Shoppers in different regions expect different payment methods — bank transfers, local wallets, real-time payment schemes — and a checkout that only offers cards can quietly lose a large share of would-be buyers in those markets. Adyen's research into embedded finance highlights the same pattern: The ultimate guide to embedded finance.
For a cross-border platform, the value of embedded payments is not just "pay in-app" — it's "pay in-app, the way each local customer expects." That means the underlying provider has to bring local payment methods to the integration, not leave the platform to source each one country by country.
This is the layer HaiPay focuses on. HaiPay's payment network spans 150+ local payment methods across key markets, which platforms typically integrate through an API, Hosted Checkout, or Components — accessing local coverage through a single integration rather than rebuilding for each new market. Method availability by market is confirmed in your quote. The exact methods available and each market's requirements vary, so the practical value is the ability to reach local methods through one integration, not an assumption that every market behaves identically.

How to choose an embedded payments provider
Once you've decided to embed payments, the real question is how much of the payment operation you want to own versus outsource. The main models trade control against complexity:
Model | What you take on | Best when |
Become a full payment facilitator (PayFac) | You underwrite and onboard your users, and carry liability for fraud, chargebacks, KYC/AML, and PCI compliance | You have scale, capital, and a dedicated payments/compliance team, and want maximum control and margin |
PayFac-as-a-Service | A provider handles the heavy compliance and infrastructure; you get monetization and a degree of control without registering as a facilitator | You want payment revenue and control without building underwriting and compliance in-house |
Standard processing / gateway | The provider owns most of the flow; you integrate acceptance | You want the fastest path and don't need to monetize the payment layer |
Merchant of Record (MoR) | A third party becomes the seller of record and takes on tax, compliance, and fraud liability | Global tax and compliance burden is your main concern |

Beyond the model, weigh these criteria — the ones that most often get overlooked until they become a problem:
- Local payment method coverage in the specific markets your users are in, not just the number of methods overall.
- Onboarding control — can you shape the experience for your users, or is it a black box bolted onto your product?
- Integration options — API, hosted checkout, and pre-built components give you room to trade build effort against control.
- Clarity on compliance and liability — who is responsible for what, and does the provider's answer match your team's capacity?
- Payouts and settlement — if you run a marketplace or pay out creators or sellers, confirm the provider supports that flow.
There is no single "best" provider — there's the one whose model and coverage fit your product and your markets.
Bring embedded payments to your platform
If you're building payments into a cross-border product, the deciding factor is usually local coverage and integration fit. Book a demo or talk to a payment specialist to see how your platform can integrate acceptance, local payment methods, and payouts through HaiPay's API, Checkout, local payment methods, and mass payouts.
Wesley Wang is part of the team at HaiPay, a payments infrastructure provider helping platforms accept and move money across borders.
Sources for the integration checklist and definitions
1. Stripe — embedded payments; supports the product-experience definition. Accessed 13 October 2026.
2. Stripe — ISV integrated payments; supports the software-workflow definition. Accessed 13 October 2026.
3. Stripe — embedded Checkout redirect behavior; payment-method-specific example. Accessed 13 October 2026.
4. HaiPay — API rules; supported interface types and uncertain-result guidance. Accessed 13 October 2026.
5. Stripe — webhook guidance; Stripe signature and duplicate-delivery behavior. Accessed 13 October 2026.
6. HaiPay — end-to-end testing; test-environment order-state and notification tools. Accessed 13 October 2026.
7. HaiPay — Direct API integration; order, result, notification and signing workflow. Accessed 13 October 2026.
FAQ
Paying for a ride inside a ride-hailing app the moment your trip ends is an embedded payment — the transaction happens inside the app, with no redirect to a separate payment page.
Integrated payments connect payment processing to software workflows. Embedded payments make payment workflows part of the platform’s product experience. The terms can overlap. Check the actual flow and responsibilities: an embedded checkout can still redirect users for payment methods that require it.
In this context, platforms typically deal with three broad categories: card payments, bank-based payments, and digital wallets and local payment methods. Which combination matters depends on the markets you serve.
Klarna's "buy now, pay later" option inside a merchant's checkout is a form of embedded finance — specifically embedded lending — which sits in the same family as embedded payments under the broader embedded finance umbrella.
Check which local payment methods are available in each target market, how checkout and payouts fit your product, and how settlement and reconciliation work. Confirm market-specific requirements and method availability in your quote before planning the rollout.
No. The payment experience can stay inside your product while a payment provider supplies the processing infrastructure behind it. Your platform still needs to define onboarding, settlement, refund and reconciliation responsibilities with that provider.