Embedded payments API: Ship payments in days, not months

Pick the wrong embedded payments application programming interface (API), and you're looking at delayed go-lives, fragmented reconciliation, and compliance work that pulls your engineering team away from the product they should be building. A bad payments provider decision can cost months of development time and leave meaningful processing revenue on the table permanently.

This guide gives vertical SaaS platform leaders a practical framework for evaluating, selecting, and integrating an embedded payments API that supports real-world payment workflows, faster onboarding, and compounding processing volume without adding unnecessary compliance or operational overhead.

Embedded payments vs. integrated payments: What the distinction means for your SaaS platform

With embedded payments, your platform owns the merchant relationship, the branding, and the processing economics. Customers onboard directly inside your software, and the embedded payments API runs the payment experience behind the scenes. Many vertical SaaS platforms do this through a payments partner that handles KYC, underwriting, and regulatory compliance on their behalf.

But integrated payments work differently. Your platform hands merchants off to a third-party provider that owns the payment relationship. That means customers leave your interface to sign up, the provider keeps most of the processing revenue, and you earn a referral fee.

Architecturally, embedded means the payment flow lives inside your product. Integrated means it lives outside of it. That distinction is where the real revenue story lives. With embedded payments, processing volume becomes part of your platform's growth model. But with integrated payments, that revenue belongs to someone else.

And the size of the opportunity is hard to ignore. Embedded finance is projected to generate more than $320 billion in global revenue by 2030, with SMB software platforms set to account for nearly half of that. Platforms that own the payment experience share directly in that growth. Platforms that don't, watch it flow to the provider.

Core embedded payments API capabilities your stack must support

Your embedded payments API needs to handle four critical capability areas before you can go live. Miss one, and you'll either delay launch or create technical debt that compounds with every merchant you onboard.

Pay-in and pay-out flows for platform architectures

Your API needs to handle both inbound payment processing and outbound merchant deposits through one integration.

Pay-in flows should support:

• Card-present and card-not-present transactions
• ACH debits (aka pay-by-bank) 
• Digital wallets and alternative payment options
• Partial captures and multi-tender transactions

Deposit flows should support:

• Configurable settlement schedules
• Split disbursements across multiple parties
• Automated reconciliation between transaction volume, fees, refunds, and chargebacks

Without native support for both flows, platforms usually end up building custom reconciliation workflows that become harder to maintain as volume grows.

Split payments, platform fees, and multi-merchant support

Multi-merchant platforms need native split-payment support. At a minimum, your embedded payments API should:

• Route funds to multiple parties in a single transaction
• Deduct platform fees automatically
• Handle additional splits like referral commissions or service provider cuts

And once you're onboarding merchants at scale, you also need automated settlement schedules, reporting, and metadata. Without these, your merchants end up reconciling by hand.

Refunds, disputes, and chargeback handling

Without built-in automation, refunds and disputes turn into operational bottlenecks fast. The essentials your provider has to cover:

• Full and partial refunds
• In-app or automated dispute evidence submission
• Webhook notifications for chargeback events
• Built-in fraud and security measures
• Split-payment reversals when platform fees are involved

Chargebacks sit with the merchant. That's how the card networks work, and no payments partner changes that. But fraud-driven chargebacks are a different story. They're preventable, and the tools your provider gives you to prevent them shape how often your merchants see them.

Rainforest offers built-in 3DS to cut down on chargebacks driven by fraud, so your merchants deal with fewer disputes and your platform spends less time in the middle of them.

Tokenization, PCI scope, and secure data handling

Your payment provider needs to tokenize credit cards and other sensitive payment data before it ever touches your infrastructure. Security features like hosted fields and client-side tokenization can keep raw card data off your servers, which reduces PCI scope and compliance burden.

The features that potentially reduce your PCI scope:

• End-to-end encryption
• Hosted payment fields or SDKs
• Token vault storage for recurring billing
• Infrastructure that meets payment security compliance standards

‍

Webhooks, idempotency, and reconciliation: Engineering non-negotiables

Three backend capabilities separate a scalable embedded payments API from one that creates long-term engineering debt: event-driven webhooks and component event listeners, idempotent APIs, and automated reconciliation.

Webhooks deliver real-time payment updates without constant polling. They fire automatically whenever a payment succeeds, fails, refunds, or enters dispute, so downstream workflows update instantly. 

At the same time, webhooks are inherently brittle. Platforms at scale should consider hardening their integrations with component event listeners and/or automations that query the payment provider’s API based on events in the platform. Your payment provider should offer multiple ways to confirm that the payment status matches between your system and their ledger.

Idempotency prevents duplicate charges during retries or network failures. Your API accepts an idempotency key with each request and returns the original result if the same one comes in again. 

Automated reconciliation ties payment data, settlements, refunds, fees, and deposits together without anyone matching by hand. This is core to the embedded payments value proposition, and it only works if your payment provider has robust logic to programmatically validate every piece of payments data and, in the event of a conflict, determine the source of truth. 

Here are four ways Rainforest verifies every single transaction: 

• In real-time against the payment networks
• In real-time against our platform partners, ensuring everyone is on the same page
• At settlement time to confirm the funds are accurate and good
• At deposit time to ensure all deposit flows are always 100% accurate between reporting and funding

Rainforest handles reconciliation through single daily deposits, itemized reports, and automated webhook events that tie transactions to settlement batches. Less overhead for the software platform’s engineering team, less matching for finance.

How to evaluate an embedded payments API provider for vertical SaaS

Choosing an embedded payments API provider shapes your revenue model, compliance exposure, and long-term product roadmap. Product owns the merchant experience, engineering owns the integration, and finance owns the unit economics. So the choice isn't just an engineering call. It's a cross-functional one, and the model you pick locks in trade-offs across all three.

That’s why you evaluate providers on ownership, operational burden, and unit economics, not just how fast the integration goes.

Which embedded payments model fits your platform

There are three models to choose from, and the right one depends on how much control, compliance responsibility, and operational overhead your platform wants to own.

Referral model in which you refer merchants to a third-party payments provider in exchange for a revenue share, with minimal integration work and no compliance responsibility. 

PayFac-as-a-Service in which you embed payments under a payments provider’s infrastructure and own the merchant experience, while the provider owns compliance and underwriting risk. 

Registered PayFac or ISO model where you become your own regulated payments provider, working directly with a sponsor bank, and take on the highest degree of control along with the most compliance and operational responsibility.

KYB/KYC ownership, underwriting, and compliance responsibilities

If you decide to choose either a referral or embedded payments model, your provider will likely handle KYC/KYB, underwriting and compliance. 

But here are two things to look out for: 

1. How much input can you provide? Will the payments provider apply a one-size-fits-all model across the board? Or are they willing to customize their underwriting and risk models to minimize fraud while also reducing friction? Look for a provider who will collaborate with you to maximize approvals while minimizing risk.  
2. Who’s liable for merchant credit losses? If the payment provider owns underwriting but the platform is liable for merchant credit losses, the platform is taking on liability for the outcomes of a process that they don’t control. 

‍

Rainforest runs merchant verification, underwriting, and regulatory compliance at the platform level, so your team never builds an internal compliance function to scale alongside payments volume. The Rainforest team works closely with every platform to optimize the underwriting and transaction monitoring models for your unique merchant profile.

Data ownership, portability, and exit terms

Before signing, confirm who owns the merchant relationship, contracts, and payment data. Some legacy providers create expensive switching costs through restrictive contracts, data lock-in, or limited portability.

Modern providers should support full data portability and flexible contract terms so your platform keeps control of the customer relationship as it scales.

Pricing, rev share, and unit economics to model before you sign

Small differences in pricing structure compound into big margin swings at scale. Model your transaction economics early, and make sure your provider gives you transaction-level reporting across merchants, payment methods, refunds, and deposits.

The variables that matter:

• Interchange-plus vs. blended pricing
• Revenue share at different processing volumes
• Per-transaction and chargeback fees
• ACH pricing strategy
• Alternative payment methods like PayPal and Venmo

Legacy processors tend to combine rigid contracts with infrastructure that limits customization and merchant experience control.

Rainforest pairs platforms with dedicated strategic support and a single API built for vertical SaaS. And because Rainforest only earns when your merchants get paid, that support acts like an embedded payments department. It pushes for adoption and volume, not fees.

How Rainforest delivers the embedded payments API infrastructure vertical SaaS teams need

Rainforest was purpose-built for vertical SaaS. The difference shows up in every part of the model. One API, transparent interchange-plus pricing, and contracts that give the platform full control of the merchant relationship and data.

As your payments partner, Rainforest gives you everything you need to launch embedded payments without the compliance overhead or fragmented integrations that slow traditional implementations down and limit growth.

You get a single embedded payments API covering merchant onboarding, card and ACH payments, Apple Pay, PayPal, Venmo, chargeback management, and reconciliation through one integration.

Our Component Studio adds white-labeled, low-code components (Merchant onboarding, Payment, Receipt, Payment report, Chargeback management, Deposit report) that drop into your product. Your engineering team ships payments in days, not months.

• ‍Runs every payment flow through one API. Pay-ins, pay-outs, split payments, and platform fees, all through a single integration.‍
• Handles merchant onboarding for you. KYB/KYC, underwriting, and payment security compliance checks run automatically through our API and pre-built components.‍
• Ships with omnichannel acceptance built in. Card, ACH, and digital wallets share the same API surface. No extra integrations to bolt on.‍
• Automates reconciliation end to end. Single daily deposits and itemized reports. Your finance team stops matching transactions by hand.‍
• Cuts fraud-driven chargebacks with built-in prevention. Tools like 3DS reduce fraud before it hits your merchants.

Rainforest is purpose-built for vertical SaaS platforms that want to own the payments experience, grow processing volume, and maximize payments revenue without taking on compliance overhead. Our embedded payments API gives you full control of merchant onboarding, pricing, and reporting.

‍

Frequently asked questions about embedded payments APIs

What is the difference between embedded payments and integrated payments?

Embedded payments let your platform own the merchant relationship, the branding, and the payment economics. Transaction volume processed inside your software becomes a revenue line, not someone else's. Integrated payments work as a referral or redirect. Your platform hands merchants off to a third-party provider that owns the payment relationship and keeps most of the processing revenue. With embedded payments, platforms share in interchange-plus margin as volume grows instead of passing most of that revenue to the provider.

What API capabilities does a vertical SaaS platform need for embedded payments?

Your embedded payments API has to cover pay-in and pay-out flows, split payments with platform fee extraction, refund and chargeback handling, and tokenization that keeps you out of payment security compliance scope. Those four are non-negotiable before you go live. Beyond the API surface, ask how your provider handles fraud prevention. Rainforest includes tools like 3DS to cut down on fraud-driven chargebacks, so your merchants deal with fewer disputes.

How long does it take to integrate an embedded payments API?

A modern cloud-based vertical SaaS platform can integrate an embedded payments API in as little as two to six weeks with a modern, purpose-built provider. Component-based integrations tend to be on the faster side, while API-only integrations may take a bit longer. Complexity in the core software product, such as multiple checkout flows or a large codebase, can also extend integration timelines. Legacy technology or poorly documented APIs can stretch that timeline to six months or more.

With Rainforest, you get a single API, interactive API docs, and low-code Component Studio that handle merchant onboarding, payment acceptance, tokenization, chargeback management, and reconciliation right out of the box. Your team focuses on embedding the UI components and mapping payment flows to your product logic. Generic processors that need separate integrations for onboarding, underwriting, fraud monitoring, and reporting balloon the timeline and create ongoing maintenance overhead.