Introduction

Embedded payments allow non-financial software platforms (like SaaS companies, marketplaces, and ERPs) to integrate payment processing directly into their core product. Instead of redirecting users to a third-party gateway, the platform acts as the payment provider, creating a seamless user experience while unlocking a massive new revenue stream through payment monetization.

For the past two decades, the relationship between software and payments was strictly transactional.

If you built a software platform—say, a practice management tool for yoga studios—your software handled the scheduling, the marketing, and the customer database. But when it came time for the yoga studio to actually charge their clients, your software had to hand the transaction off to a third-party payment gateway like PayPal or Authorize.Net.

The yoga studio had to leave your platform, create a separate account with the payment gateway, negotiate their own processing rates, and then manually connect the two systems using API keys.

This model created massive friction for the user and left a tremendous amount of money on the table for the software platform.

That era is ending. The future of software is Embedded Payments.

Embedded payments (often referred to as Integrated Payments or Payment Facilitation) represent a fundamental shift in fintech infrastructure. It allows any software company to essentially become a fintech company.

By embedding the payment infrastructure directly into the software, the platform controls the entire user experience. The yoga studio signs up for the software and is instantly approved to accept credit cards, without ever leaving the platform or interacting with a third-party bank.

More importantly, the software platform gets to monetize those payments, earning a percentage of every transaction processed through their system. For many SaaS companies, embedded payments generate more revenue than their core software subscriptions.

This comprehensive guide will explore the mechanics, the business models, and the technical infrastructure of embedded payments.

We will break down the different integration models—from simple referral partnerships to full Payment Facilitation (PayFac). We will examine the compliance and risk management responsibilities that come with handling other people’s money. And we will provide a roadmap for software platforms looking to build, launch, and scale an embedded payment solution.

Whether you are a B2B SaaS founder looking to double your Average Revenue Per User (ARPU) or a marketplace operator seeking to streamline payouts to your vendors, understanding embedded fintech infrastructure is the key to unlocking the next stage of your company’s growth.

Table of Contents

  1. Introduction
  2. Chapter 1: The Evolution of Software and Payments
  3. Chapter 2: The Business Case for Embedded Payments
  4. Chapter 3: The Payment Facilitator (PayFac) Model
  5. Chapter 4: PayFac-as-a-Service (The Modern Solution)
  6. Chapter 5: The Mechanics of Embedded Onboarding (KYC/AML)
  7. Chapter 6: Monetization Strategies (How Software Platforms Make Money)
  8. Chapter 7: The Technical Architecture of Embedded Payments
  9. Chapter 8: Risk Management and Fraud Prevention in Embedded Payments
  10. Chapter 9: Embedded Payments for Marketplaces (Split Payments)
  11. Chapter 10: The Future of Embedded Finance (Beyond Payments)
  12. Chapter 11: Frequently Asked Questions (FAQ)
  13. Chapter 12: The Challenges of Global Embedded Payments
  14. Chapter 13: The Build vs. Buy Decision for Embedded Payments
  15. Chapter 14: The Impact of Embedded Payments on B2B Transactions
  16. Chapter 15: The Importance of Developer Experience (DX) in Embedded Payments
  17. Conclusion: The Strategic Imperative of Embedded Finance

Chapter 1: The Evolution of Software and Payments

The integration of software and payments has evolved through three distinct phases: the Referral Model (where software simply redirects users to a gateway), the Integrated Model (where software connects via API but the user still holds a separate merchant account), and the Embedded Model (where the software platform acts as the payment provider).

To understand the power of embedded payments, we must look at how the relationship between software platforms (Independent Software Vendors, or ISVs) and payment processors has evolved.

Phase 1: The Referral Model (The “Hands-Off” Approach)

In the early days of SaaS, software platforms wanted nothing to do with payments. Handling credit cards meant dealing with PCI compliance, fraud, and complex banking regulations.

The standard approach was the Referral Model.

  1. A restaurant signs up for a new Point of Sale (POS) software.
  2. The POS software tells the restaurant, “We don’t process payments. Go sign up for an account with First Data or TSYS.”
  3. The restaurant spends weeks negotiating with the bank, filling out paperwork, and waiting for approval.
  4. Once approved, the restaurant receives a physical terminal or an API key and manually connects it to the POS software.

The Result: The user experience was terrible. The onboarding process took weeks. And the software platform earned zero revenue from the millions of dollars flowing through their system.

Phase 2: The Integrated Model (The API Connection)

As APIs became more robust, software platforms began building direct integrations to payment gateways (like Stripe or Braintree).

  1. The restaurant signs up for the POS software.
  2. Inside the software dashboard, there is a button that says “Connect with Stripe.”
  3. The restaurant clicks the button, is redirected to Stripe’s website, creates an account, and is redirected back to the POS software.

The Result: The user experience improved significantly. Onboarding took minutes instead of weeks. However, the restaurant still had a direct relationship with Stripe, not the software platform. The software platform might earn a small “revenue share” (e.g., 10 basis points) from Stripe for the referral, but Stripe kept the lion’s share of the profit and owned the customer relationship.

Phase 3: The Embedded Model (The Platform as the Processor)

The current evolution is the Embedded Model (often powered by Payment Facilitation or “PayFac-as-a-Service”).

In this model, the software platform completely white-labels the payment experience.

  1. The restaurant signs up for the POS software.
  2. During the software onboarding, they provide their business details and bank account information.
  3. In the background, the software platform instantly underwrites and approves the restaurant to accept payments.
  4. The restaurant begins processing credit cards immediately. They never see the name of the underlying acquiring bank or payment gateway. They only see the software platform’s brand.

The Result: The user experience is frictionless. The software platform owns the entire customer relationship. Most importantly, the software platform controls the pricing and keeps the majority of the payment processing margin, transforming payments from a cost center into a massive profit center.

Chapter 2: The Business Case for Embedded Payments

Software platforms adopt embedded payments to achieve three primary business objectives: creating a frictionless user onboarding experience, increasing customer retention (reducing churn) by deeply integrating into the user’s financial operations, and unlocking a massive new revenue stream by monetizing the transaction volume flowing through their platform.

Transitioning to an embedded payment model requires significant engineering resources and operational changes. Why are thousands of SaaS companies and marketplaces making this investment?

The business case for embedded payments rests on three pillars: User Experience, Retention, and Monetization.

Pillar 1: Frictionless User Experience

In the modern software landscape, the company with the easiest onboarding process wins.

If a small business owner signs up for your invoicing software, their primary goal is to get paid by their clients as quickly as possible.

If you force them to leave your platform, apply for a third-party merchant account, wait three days for underwriting approval, and then figure out how to copy and paste API keys, you have introduced massive friction. Many users will simply abandon the setup process.

Embedded payments allow you to offer “Instant Onboarding.” The user provides their basic business information during the software signup, and your platform instantly provisions a sub-merchant account in the background. They can send their first invoice and accept a credit card payment within five minutes of creating their account.

Pillar 2: Increased Customer Retention (Stickiness)

Software is relatively easy to replace. If a user finds a cheaper scheduling tool, they might cancel their subscription and switch.

Financial infrastructure is incredibly difficult to replace.

When you embed payments into your software, you become the financial nervous system of your customer’s business. You are handling their daily cash flow, their payouts, and their financial reporting.

If a user wants to leave your platform, they aren’t just canceling a software subscription; they are ripping out their entire payment processing system, which disrupts their cash flow and requires them to find a new processor.

This deep integration creates massive “stickiness.” SaaS companies that successfully implement embedded payments typically see their customer churn rates drop by 30% to 50%.

Pillar 3: Massive Revenue Expansion (Monetization)

This is the primary driver of the embedded payments boom.

In a traditional SaaS model, your revenue is capped by your subscription fee. If you charge $100/month, you make $1,200 a year per customer, regardless of how successful that customer is.

If that customer processes $1,000,000 a year through your software, the third-party payment processor (like Stripe or Square) is making $29,000 a year in processing fees (assuming a 2.9% rate), while you are still only making $1,200.

Embedded payments allow you to capture that margin.

By acting as the payment provider, you buy processing at wholesale rates (Interchange) and sell it to your users at retail rates (e.g., 2.9% + $0.30).

If you capture just 0.50% (50 basis points) of margin on that $1,000,000 in volume, you earn an additional $5,000 a year from that customer. You have just increased your Average Revenue Per User (ARPU) by over 400% without raising your software subscription price.

For many mature SaaS platforms (like Shopify, Mindbody, or Toast), payment monetization now generates significantly more revenue than their core software subscriptions.

Chapter 3: The Payment Facilitator (PayFac) Model

A Payment Facilitator (PayFac) is a master merchant that holds a direct relationship with an acquiring bank and is authorized to underwrite and onboard “sub-merchants” (their software users) instantly. The PayFac assumes full financial liability for the transactions processed by its sub-merchants, including chargebacks and fraud, in exchange for keeping the majority of the processing margin.

To understand how embedded payments actually work under the hood, you must understand the concept of Payment Facilitation.

The Payment Facilitator (PayFac) model is the regulatory and financial framework that allows a software company to act like a payment processor.

The Traditional Merchant Account Model

Historically, every business that wanted to accept credit cards had to obtain their own, individual Merchant Account directly from an acquiring bank.

The bank had to perform rigorous underwriting on every single business: checking the owner’s credit score, reviewing their financial statements, and assessing their business model for risk. This process was slow, expensive, and completely incompatible with the instant onboarding expected in modern software.

The PayFac Innovation

The card networks (Visa/Mastercard) recognized this bottleneck and created the Payment Facilitator framework.

In the PayFac model, the acquiring bank does not underwrite the individual small businesses. Instead, the bank underwrites the software platform itself.

  1. The Master Account: The software platform (the ISV) applies to become a registered Payment Facilitator. The acquiring bank performs massive, institutional-level underwriting on the software platform.
  2. The Sub-Merchants: Once approved, the software platform is granted a “Master Merchant Account.” The platform is now legally authorized to instantly onboard its own users as “Sub-Merchants” under its master account.
  3. Instant Onboarding: When a yoga studio signs up for the software, the platform performs a quick, automated identity check (KYC/AML) and instantly provisions a sub-merchant account. The acquiring bank never interacts with the yoga studio.
  4. The Flow of Funds: When a customer pays the yoga studio, the funds flow from the customer’s issuing bank, to the acquiring bank, into the PayFac’s master settlement account. The PayFac then calculates its fees and initiates a payout to the yoga studio’s bank account.

The Catch: Financial Liability

The PayFac model grants the software platform incredible power: instant onboarding, complete control over the user experience, and the ability to set retail pricing and keep the margin.

However, this power comes with a massive catch: Absolute Financial Liability.

Because the acquiring bank did not underwrite the individual sub-merchants, the bank refuses to take the risk. The risk is entirely shifted to the PayFac.

If the yoga studio processes $50,000 in fraudulent transactions, goes bankrupt, and cannot cover the resulting chargebacks, the acquiring bank will simply deduct that $50,000 directly from the PayFac’s master settlement account.

The software platform is now on the hook for the loss.

Becoming a full, registered PayFac requires building an entire risk, compliance, and underwriting department to monitor sub-merchants and prevent fraud. It is a massive operational undertaking that typically requires millions of dollars in upfront investment and dedicated banking relationships.

Chapter 4: PayFac-as-a-Service (The Modern Solution)

PayFac-as-a-Service (PFaaS) allows software platforms to embed payments and monetize transactions without the massive upfront costs, regulatory burden, and financial liability of becoming a full, registered Payment Facilitator. The PFaaS provider handles the underwriting, compliance (KYC/AML), and chargeback risk, while the software platform controls the user experience and earns a revenue share.

For years, the embedded payments landscape was binary.

You either used the Referral/Integrated model (zero risk, zero control, zero revenue) or you spent millions of dollars and two years building the infrastructure to become a full Payment Facilitator (total control, massive revenue, massive risk).

This created a massive barrier to entry for mid-market SaaS companies and startups.

The solution that has revolutionized the industry is PayFac-as-a-Service (PFaaS), also known as Managed Payment Facilitation.

The PFaaS Model

In the PFaaS model, a specialized fintech company (like Stripe Connect, Finix, or NMI’s Facilipay) acts as the registered Payment Facilitator.

They have already done the heavy lifting: securing the acquiring bank relationships, building the underwriting algorithms, and establishing the compliance frameworks.

They offer this infrastructure to software platforms via API.

  1. The White-Label Experience: The software platform uses the PFaaS provider’s APIs to build a completely white-labeled onboarding flow. The yoga studio signs up for the software and provides their business details directly within the software’s UI.
  2. The API Handoff: The software platform securely transmits this data to the PFaaS provider via API.
  3. The Instant Underwriting: The PFaaS provider’s automated systems perform the KYC/AML checks and instantly approve the sub-merchant.
  4. The Revenue Share: The software platform sets the retail pricing for their users (e.g., 2.9% + $0.30). The PFaaS provider charges the software platform a wholesale rate (e.g., Interchange + 0.40% + $0.10). The software platform keeps the difference (the margin).

The Crucial Difference: Risk and Liability

The defining characteristic of PFaaS is the transfer of risk.

In a full PayFac model, the software platform is financially liable for every chargeback and fraudulent transaction processed by its sub-merchants.

In the PFaaS model, the PFaaS provider assumes the financial liability.

If the yoga studio processes $50,000 in fraudulent transactions and goes bankrupt, the PFaaS provider absorbs the loss, not the software platform.

The PFaaS provider also handles the complex regulatory compliance, including:

  • KYC (Know Your Customer): Verifying the identity of the business owners.
  • AML (Anti-Money Laundering): Monitoring transactions for suspicious activity and reporting to government agencies (like FinCEN).
  • OFAC Checks: Ensuring the sub-merchants are not on international sanctions lists.
  • 1099-K Reporting: Issuing the required tax forms to the sub-merchants at the end of the year.

The Trade-Off

PFaaS offers the best of both worlds: the frictionless user experience and revenue monetization of a full PayFac, without the massive upfront investment and financial liability.

The trade-off is margin.

Because the PFaaS provider is taking the risk and handling the compliance, they charge a higher wholesale rate than an acquiring bank would charge a full PayFac.

A full PayFac might earn 80 basis points (0.80%) of margin on a transaction, while a software platform using PFaaS might only earn 40 basis points (0.40%).

However, for 95% of software platforms, giving up half the margin is a small price to pay to avoid the operational nightmare of building an in-house risk and compliance department.

Chapter 5: The Mechanics of Embedded Onboarding (KYC/AML)

Embedded onboarding requires software platforms to collect specific data points (Legal Business Name, EIN/Tax ID, Owner’s SSN, and Bank Account details) during signup. This data is instantly transmitted via API to the payment provider, which runs automated Know Your Customer (KYC) and Anti-Money Laundering (AML) checks against government databases to approve the sub-merchant in seconds.

The core value proposition of embedded payments is the “Instant Onboarding” experience.

To achieve this, the software platform must seamlessly integrate the complex regulatory requirements of the banking system into their user signup flow.

When a business applies for a traditional merchant account, the bank requires a massive stack of paperwork to satisfy federal KYC (Know Your Customer) and AML (Anti-Money Laundering) regulations.

In an embedded model, this process is digitized and automated via API.

The Required Data Payload

To instantly underwrite a sub-merchant, the software platform must collect a specific set of data points during the onboarding flow.

Business Information:

  • Legal Business Name (and DBA, if applicable)
  • Business Address
  • Employer Identification Number (EIN) or Tax ID
  • Business Type (LLC, Sole Proprietorship, Corporation)
  • Website URL
  • Expected Annual Processing Volume

Beneficial Owner Information (The KYC Requirement):

Federal law requires financial institutions to identify the “Beneficial Owners” of any business opening an account (typically anyone owning 25% or more of the company).

  • Full Legal Name
  • Home Address
  • Date of Birth
  • Social Security Number (SSN) or National ID

Payout Information:

  • Bank Routing Number
  • Bank Account Number

The Automated Underwriting Process

Once the software platform collects this data, it sends a single API payload to the payment provider (the PayFac or PFaaS provider).

The provider’s automated systems instantly execute a series of checks:

  1. Identity Verification (KYC): The system pings credit bureaus and public records databases (like LexisNexis or Equifax) to verify that the Beneficial Owner’s Name, Address, DOB, and SSN match.
  2. Business Verification (KYB): The system verifies the EIN and Legal Business Name against IRS or state registry databases.
  3. Sanctions Screening (OFAC): The system checks the names against the Office of Foreign Assets Control (OFAC) list to ensure the individuals are not known terrorists or money launderers.
  4. MATCH List Check: The system checks the Mastercard Alert to Control High-risk (MATCH) list to ensure the business hasn’t been previously terminated by another acquiring bank for fraud or excessive chargebacks.

Handling Exceptions (The “Manual Review”)

In a well-designed embedded onboarding flow, 80% to 90% of sub-merchants will pass these automated checks and be approved instantly.

However, 10% to 20% will fail the automated checks.

This usually happens due to simple data entry errors (e.g., a typo in the SSN, or a business address that doesn’t match the IRS records).

When this occurs, the API returns a “Pending” or “Manual Review” status.

The software platform must have a UI workflow to handle these exceptions gracefully.

  • The platform prompts the user to upload supporting documentation (e.g., a photo of their Driver’s License or a voided check).
  • This documentation is securely transmitted via API to the payment provider’s risk team for manual verification.
  • Once verified, the status is updated to “Approved.”

Designing a frictionless exception-handling workflow is critical to maximizing the conversion rate of your embedded payment solution.

Chapter 6: Monetization Strategies (How Software Platforms Make Money)

Software platforms monetize embedded payments primarily through the “Buy Rate vs. Sell Rate” spread. The platform negotiates a wholesale processing rate (e.g., Interchange + 0.20%) with their payment provider and sets a retail rate (e.g., 2.9% + $0.30) for their users, keeping the difference as pure profit on every transaction processed.

The transition from a SaaS subscription model to an embedded payments model fundamentally changes the unit economics of a software company.

Instead of fighting to acquire new users to increase Monthly Recurring Revenue (MRR), the platform can dramatically increase revenue simply by helping their existing users process more volume.

There are several strategies for monetizing embedded payments.

Strategy 1: The Processing Spread (The Core Engine)

This is the most common and lucrative monetization strategy.

The software platform acts as a reseller of payment processing.

  1. The Buy Rate (Wholesale): The platform negotiates a wholesale rate with their PFaaS provider or acquiring bank. This is typically structured as Interchange++ (e.g., Interchange + Network Fees + 0.20% + $0.10 per transaction).
  2. The Sell Rate (Retail): The platform sets the pricing for their sub-merchants. This is typically a simple, flat rate (e.g., 2.90% + $0.30 per transaction), similar to what Stripe or Square charges.
  3. The Margin: The platform keeps the difference between the Buy Rate and the Sell Rate.

Example Calculation:

  • A sub-merchant processes a $100 transaction using a standard Visa rewards card.
  • The Interchange + Network Fees cost $1.80.
  • The PFaaS provider’s wholesale markup is $0.30 (0.20% + $0.10).
  • Total Wholesale Cost (Buy Rate): $2.10
  • The software platform charges the sub-merchant 2.90% + $0.30.
  • Total Retail Revenue (Sell Rate): $3.20
  • The Platform’s Profit (The Spread): $1.10

If that sub-merchant processes $10,000 a month, the software platform earns $110 a month in pure profit, simply for facilitating the payments. Multiply that by 1,000 sub-merchants, and the platform has added $1.3 million in high-margin annual recurring revenue.

Strategy 2: SaaS + Payments Bundling

Many platforms use embedded payments to drive adoption of their core software.

  • The “Free” Software Model: The platform offers their core scheduling or invoicing software for free, completely eliminating the barrier to entry. They monetize entirely on the backend through the payment processing spread. This is the model used by companies like Toast (restaurant POS) and Mindbody (fitness software).
  • The Discounted SaaS Model: The platform charges $100/month for their software. However, if the user agrees to use the platform’s embedded payment solution, the software subscription is discounted to $50/month. The platform easily recoups the $50 discount through the payment processing margin, while significantly increasing user retention.

Strategy 3: Value-Added Financial Services

Once a platform has embedded payments and controls the flow of funds, they can introduce additional, highly profitable financial products.

  • Instant Payouts: Standard payment settlement takes 2-3 business days. The platform can offer “Instant Payouts” (depositing funds into the sub-merchant’s debit card within 30 minutes) for an additional 1.00% fee.
  • Capital/Lending: Because the platform sees the sub-merchant’s daily cash flow, they can underwrite loans or merchant cash advances with incredible accuracy. The platform offers a $10,000 loan, and automatically deducts 10% of daily sales until the loan (plus a fixed fee) is repaid.
  • Issuing (Card Creation): The platform can issue physical or virtual debit cards to their sub-merchants. When the sub-merchant spends their balance using the platform’s card, the platform earns a percentage of the interchange fee from the card network.

These value-added services transform a simple SaaS company into a comprehensive financial operating system for their users.

Chapter 7: The Technical Architecture of Embedded Payments

The technical architecture of embedded payments relies on a suite of APIs provided by the PayFac or PFaaS partner. These APIs handle three distinct functions: Onboarding (transmitting KYC data to create sub-merchant accounts), Processing (tokenizing cards and executing charges), and Funding (managing the complex flow of funds, split payments, and payouts to sub-merchants).

Building an embedded payment solution is a significant engineering project. It requires integrating a complex set of financial APIs into your core software platform.

Unlike a simple payment gateway integration (where you just need an API to charge a card), embedded payments require APIs to manage the entire lifecycle of a merchant account.

The Three Pillars of the API Architecture

A robust embedded payments integration consists of three distinct API pillars:

1. The Onboarding API (The Identity Layer)

This is the API that replaces the traditional, paper-based merchant application.

  • The Payload: Your software collects the business and owner details (Name, Address, SSN, EIN, Bank Account) during your signup flow.
  • The Request: Your backend server sends this data as a JSON payload to the Onboarding API.
  • The Response: The API returns a status (Approved, Pending, or Declined) and a unique sub_merchant_id.
  • The Webhooks: Because identity verification can sometimes take a few minutes (or require manual review), your system must listen for asynchronous webhooks (e.g., account.updated) to know when the sub-merchant is fully approved to process live transactions.

2. The Processing API (The Transaction Layer)

This is the API that actually moves the money from the customer’s credit card.

  • Client-Side Tokenization: To keep your software platform out of PCI SAQ D scope, you must use the payment provider’s frontend SDK (e.g., secure iFrames) to collect the raw credit card data directly from the customer’s browser.
  • The Token: The SDK returns a secure token to your frontend, which passes it to your backend.
  • The Charge Request: Your backend sends an API request to the Processing API. Crucially, this request must include the sub_merchant_id (obtained during onboarding) so the payment provider knows which specific sub-merchant is receiving the funds.
  • The Response: The API returns the authorization status (Approved or Declined).

3. The Funding API (The Payout Layer)

This is the most complex part of the architecture, as it handles the actual movement of settled funds to the sub-merchants’ bank accounts.

  • The Master Account: When transactions are processed, the funds initially settle into the PayFac’s (or PFaaS provider’s) master settlement account.
  • The Split: The Funding API calculates the fees. If a $100 transaction was processed, and your platform charges a 3.00% fee, the API splits the funds: $97 is allocated to the sub-merchant, and $3 is allocated to your platform’s revenue account.
  • The Payout: The API automatically initiates an ACH transfer (or instant payout) to deposit the $97 into the sub-merchant’s bank account, typically on a T+2 (two business days) schedule.
  • The Reconciliation: The API provides detailed reporting endpoints so your software can display accurate payout ledgers and fee summaries within your user dashboard.

The Importance of Webhooks

In an embedded payments architecture, webhooks are not optional; they are mandatory.

Because you are managing the financial operations of thousands of sub-merchants, your system must react to asynchronous events in real-time.

  • Disputes: If a customer files a chargeback against one of your sub-merchants, the payment provider will send a dispute.created webhook. Your software must instantly notify the sub-merchant and provide a UI for them to upload compelling evidence to fight the chargeback.
  • Payout Failures: If a sub-merchant enters an incorrect bank routing number, the ACH payout will fail. The provider will send a payout.failed webhook. Your software must automatically suspend their payouts and prompt them to update their banking details.

Chapter 8: Risk Management and Fraud Prevention in Embedded Payments

Risk management in embedded payments involves monitoring sub-merchants for fraudulent activity and excessive chargebacks. Even in a PFaaS model where the provider assumes financial liability, software platforms must implement robust fraud monitoring tools (like velocity checks and transaction limits) to prevent bad actors from exploiting their platform and jeopardizing their master merchant account.

When you embed payments into your software, you become a target for fraudsters.

If your platform makes it incredibly easy to sign up and start processing credit cards instantly, bad actors will attempt to exploit that frictionless onboarding.

The Two Types of Fraud

In embedded payments, you must defend against two distinct types of fraud:

  1. Transaction Fraud (The Customer): A legitimate sub-merchant (e.g., a real yoga studio) processes a stolen credit card presented by a fraudulent customer. This results in a chargeback.
  2. Merchant Fraud (The User): A fraudster signs up for your software, creates a fake sub-merchant account using stolen identity details, and processes stolen credit cards through their own account, cashing out the funds before the chargebacks arrive. This is known as “Bust-Out Fraud” or “Collusion.”

The Liability Shift

As discussed in Chapter 4, the PFaaS model shifts the ultimate financial liability for these losses to the payment provider.

However, this does not mean the software platform can ignore risk management.

If your platform consistently onboards fraudulent sub-merchants, or if your legitimate sub-merchants consistently exceed the 1.00% chargeback threshold, the PFaaS provider will terminate your master account.

If you lose your payment provider, your embedded payments revenue drops to zero overnight, and your legitimate users are left stranded without a way to process payments.

Implementing Risk Controls

To protect your platform, you must implement robust risk controls alongside your payment provider’s underwriting.

  • Velocity Limits: Implement strict processing limits for new sub-merchants. For example, a new account might be capped at processing $5,000 per week. If they attempt to process a $10,000 transaction on day one, the system automatically flags the account for manual review.
  • Delayed Payouts: For high-risk sub-merchants or new accounts, delay the ACH payouts from T+2 to T+7. This provides a buffer window. If the transactions were fraudulent, the chargebacks will likely arrive before the funds are paid out, allowing the provider to freeze the money.
  • Transaction Monitoring: Integrate third-party fraud scoring tools (like Sift or Kount) into your processing flow. These tools analyze the device fingerprint and IP address of the customer making the purchase, blocking high-risk transactions before they hit the acquiring bank.
  • Ongoing KYC: Risk management doesn’t end at onboarding. If a sub-merchant suddenly changes their bank account details and immediately attempts to process a massive volume of transactions, your system should automatically suspend their payouts until their identity is re-verified.

By actively managing risk, software platforms ensure the long-term stability and profitability of their embedded payments program.

Chapter 9: Embedded Payments for Marketplaces (Split Payments)

Marketplaces (like Uber, Airbnb, or Etsy) require specialized embedded payment infrastructure to handle “Split Payments.” When a customer makes a single purchase, the payment API must dynamically split the funds, routing the commission to the marketplace’s revenue account and the remaining balance to the specific vendor or driver who provided the service.

While B2B SaaS platforms use embedded payments to monetize their users’ processing volume, multi-sided marketplaces use embedded payments to solve a fundamental operational challenge: the flow of funds.

A marketplace connects buyers with sellers (or riders with drivers).

When a buyer makes a purchase, the money cannot simply go into the marketplace’s corporate bank account. If it does, the marketplace assumes massive regulatory liability and operational overhead in manually paying out thousands of individual sellers.

The Regulatory Hurdle: Money Transmission

If a marketplace accepts funds from a buyer on behalf of a seller, holds those funds in their own bank account, and then transfers them to the seller, they are acting as a “Money Transmitter.”

In the United States, operating as a Money Transmitter requires obtaining licenses in almost every individual state—a process that takes years and costs millions of dollars in legal fees and surety bonds.

The Solution: Split Payments via API

Embedded payment providers (like Stripe Connect or Braintree Marketplace) solve this regulatory hurdle by handling the flow of funds entirely within the banking system.

The marketplace never actually touches the seller’s money.

The Split Payment Workflow:

  1. The Purchase: A customer buys a $100 handmade craft on a marketplace (e.g., Etsy).
  2. The API Request: The marketplace’s backend sends a single charge request to the Processing API. Crucially, this request includes a destination parameter (the specific seller’s sub_merchant_id) and an application_fee parameter (the marketplace’s commission, e.g., $10).
  3. The Authorization: The payment provider authorizes the $100 charge on the customer’s credit card.
  4. The Split (The Magic): When the funds settle, the payment provider’s ledger automatically splits the money.
    • $90 is routed directly to the seller’s sub-merchant account balance.
    • $10 is routed to the marketplace’s revenue account.
  5. The Payout: The payment provider initiates an ACH transfer of $90 directly to the seller’s bank account.

Because the marketplace never took possession of the $90, they are not acting as a Money Transmitter. The regulatory burden remains entirely with the payment provider.

Complex Routing Scenarios

Marketplace payment APIs must handle incredibly complex routing scenarios:

  • One-to-Many: A customer buys three items from three different sellers in a single $150 checkout cart. The API must authorize one $150 charge, but split the funds four ways (to Seller A, Seller B, Seller C, and the marketplace commission).
  • Delayed Payouts (Escrow): In a service marketplace (like a freelance platform), the funds must be held in escrow until the service is completed. The API authorizes the charge upfront, but the marketplace uses a separate API call to trigger the payout to the freelancer only after the buyer approves the work.
  • Reversals and Refunds: If a buyer requests a refund, the API must automatically claw back the $90 from the seller’s account and the $10 from the marketplace’s account to refund the full $100 to the buyer.

Mastering these complex API flows is the technical foundation of any successful multi-sided marketplace.

Chapter 10: The Future of Embedded Finance (Beyond Payments)

The future of embedded finance extends far beyond payment processing. Software platforms are evolving into comprehensive financial operating systems by embedding lending (merchant cash advances), card issuing (virtual and physical debit cards), and business banking (deposit accounts) directly into their core products, creating entirely new, high-margin revenue streams.

Embedded payments are just the beginning.

Once a software platform has successfully integrated payment processing and controls the flow of funds for its users, it has established the foundational infrastructure to offer a complete suite of financial products.

This evolution is known as Embedded Finance.

The goal is to transform the software platform from a simple workflow tool into the primary financial operating system for the business.

The Progression of Embedded Finance

The typical journey of a successful SaaS platform follows a predictable path:

  1. Core Software: The platform solves a specific business problem (e.g., scheduling for salons, inventory management for retailers).
  2. Embedded Payments: The platform integrates payment processing, allowing users to accept credit cards seamlessly. The platform monetizes the transaction volume.
  3. Embedded Lending (Capital): Because the platform sees the user’s daily cash flow (from the embedded payments), it can underwrite loans with incredible accuracy. The platform offers a $10,000 merchant cash advance, automatically deducting 10% of daily sales until the advance (plus a fixed fee) is repaid.
  4. Embedded Issuing (Cards): The platform issues physical or virtual debit cards to its users. When the user spends their balance using the platform’s card, the platform earns a percentage of the interchange fee from the card network.
  5. Embedded Banking (Accounts): The platform partners with a sponsor bank to offer FDIC-insured deposit accounts directly within the software dashboard. The user no longer needs a traditional business bank account; their software platform is their bank.

The Power of Embedded Lending

Embedded lending is particularly lucrative for software platforms.

Traditional banks struggle to underwrite small business loans because they lack real-time data. They rely on outdated tax returns and credit scores.

A software platform with embedded payments has perfect, real-time visibility into the business’s health. They know exactly how much revenue the business generated yesterday, their average order value, and their chargeback ratio.

This data advantage allows the platform to offer pre-approved capital instantly, with significantly lower default rates than traditional lenders.

Companies like Shopify (Shopify Capital) and Square (Square Loans) have built massive, highly profitable lending businesses on top of their embedded payment infrastructure.

The Power of Embedded Issuing

Embedded issuing (creating custom debit or credit cards) creates a closed-loop financial ecosystem.

Imagine a restaurant POS platform that offers embedded payments. The restaurant processes $5,000 in sales on a Friday night.

Normally, those funds are paid out to the restaurant’s external bank account on Monday.

With embedded issuing, the platform issues a custom “Restaurant Pro Debit Card” to the owner. The $5,000 in sales is instantly available on that card on Friday night.

When the owner uses that card on Saturday morning to buy $1,000 worth of supplies at a wholesale grocer, the software platform earns a portion of the interchange fee (typically 1.00% to 1.50%) from the grocer’s acquiring bank.

The platform monetized the money when it came in (embedded payments), and they monetized the money when it went out (embedded issuing).

The “Super App” Vision

The ultimate vision of embedded finance is the creation of B2B “Super Apps.”

A small business owner will log into a single software platform to manage their employees, track their inventory, accept payments from customers, pay their vendors, access working capital, and manage their business bank account.

The software platform becomes indispensable, and the monetization potential is virtually limitless.

Chapter 11: Frequently Asked Questions (FAQ)

This section addresses common questions regarding embedded payments, including the difference between the Integrated and Embedded models, the definition of a Payment Facilitator (PayFac), how software platforms monetize transaction volume, and the regulatory requirements (KYC/AML) necessary for instant sub-merchant onboarding.

What is the difference between Integrated Payments and Embedded Payments?

Answer: In the Integrated model, the software platform connects to a third-party gateway (like Stripe) via API, but the user must leave the platform to create a separate merchant account with that gateway. The gateway owns the customer relationship and the majority of the revenue. In the Embedded model, the software platform acts as the payment provider. The user is onboarded instantly within the software’s UI, and the platform controls the pricing, the user experience, and the revenue margin.

What is a Payment Facilitator (PayFac)?

Answer: A Payment Facilitator is a master merchant that holds a direct relationship with an acquiring bank. The PayFac is authorized to instantly underwrite and onboard its own users as “sub-merchants” under its master account. The PayFac assumes full financial liability for the transactions processed by its sub-merchants, including chargebacks and fraud, in exchange for keeping the majority of the processing margin.

How do software platforms make money from Embedded Payments?

Answer: Software platforms monetize embedded payments primarily through the “Buy Rate vs. Sell Rate” spread. The platform negotiates a wholesale processing rate (e.g., Interchange + 0.20%) with their payment provider and sets a retail rate (e.g., 2.9% + $0.30) for their users. The platform keeps the difference as pure profit on every transaction processed through their system.

What is PayFac-as-a-Service (PFaaS)?

Answer: PFaaS allows software platforms to embed payments and monetize transactions without the massive upfront costs and financial liability of becoming a full, registered Payment Facilitator. The PFaaS provider (like Stripe Connect or NMI’s Facilipay) handles the underwriting, compliance (KYC/AML), and chargeback risk, while the software platform controls the user experience and earns a revenue share.

Why is KYC/AML required for Embedded Payments?

Answer: Federal law requires financial institutions to verify the identity of anyone opening an account to prevent money laundering and terrorism financing. In an embedded model, the software platform must collect specific data points (Legal Business Name, EIN, Owner’s SSN) during signup. This data is instantly transmitted via API to the payment provider, which runs automated Know Your Customer (KYC) and Anti-Money Laundering (AML) checks against government databases.

What is a “Split Payment” and why do marketplaces need it?

Answer: Marketplaces (like Uber or Etsy) connect buyers with sellers. When a customer makes a purchase, the payment API must dynamically split the funds, routing the commission to the marketplace’s revenue account and the remaining balance to the specific seller. If the marketplace simply held all the funds in their own bank account before paying the sellers, they would be acting as an unlicensed “Money Transmitter,” assuming massive regulatory liability.

How does Embedded Payments reduce customer churn?

Answer: When a software platform embeds payments, it becomes the financial nervous system of its customer’s business, handling their daily cash flow and payouts. If a user wants to leave the platform, they aren’t just canceling a software subscription; they are ripping out their entire payment processing system. This deep integration creates massive “stickiness,” often reducing customer churn rates by 30% to 50%.

What is Embedded Lending?

Answer: Embedded lending is the next evolution of embedded finance. Because a software platform with embedded payments has perfect, real-time visibility into a business’s daily cash flow, it can underwrite loans or merchant cash advances with incredible accuracy. The platform offers capital instantly and automatically deducts a percentage of daily sales until the advance is repaid, creating a highly profitable new revenue stream.

What is Embedded Issuing?

Answer: Embedded issuing allows a software platform to create custom physical or virtual debit cards for its users. When the user spends their balance using the platform’s card, the platform earns a percentage of the interchange fee from the card network. This creates a closed-loop financial ecosystem where the platform monetizes the money coming in (embedded payments) and the money going out (embedded issuing).

How long does it take to implement Embedded Payments?

Answer: The timeline depends on the chosen model. Building the infrastructure to become a full, registered Payment Facilitator can take 12 to 24 months and cost millions of dollars. Implementing a PayFac-as-a-Service (PFaaS) solution via API typically takes 3 to 6 months of engineering effort, allowing the software platform to launch their embedded payment offering much faster and with significantly less risk.

Conclusion: The Strategic Imperative of Embedded Finance

Embedded payments are no longer a luxury for software platforms; they are a strategic imperative. By transforming payments from a cost center into a massive profit center, software companies can dramatically increase their Average Revenue Per User (ARPU), reduce customer churn, and establish the foundational infrastructure necessary to evolve into comprehensive financial operating systems.

The era of software companies simply referring their users to third-party payment gateways is over.

In today’s hyper-competitive SaaS landscape, the companies that win are the ones that remove all friction from the user experience and deeply integrate themselves into their customers’ daily operations.

Embedded payments achieve both of these goals simultaneously.

By offering instant onboarding, you eliminate the biggest hurdle to user adoption. By handling the flow of funds, you become the financial nervous system of your customer’s business, making your software incredibly “sticky” and difficult to replace.

Most importantly, embedded payments unlock a massive new revenue stream. By capturing the margin on the transaction volume flowing through your platform, you can double or triple your revenue without acquiring a single new user or raising your subscription prices.

Whether you choose to build the infrastructure to become a full Payment Facilitator or leverage the speed and simplicity of PayFac-as-a-Service (PFaaS), the decision to embed payments is one of the most consequential strategic choices a software company can make.

It is the first step on the journey toward Embedded Finance—the evolution from a simple workflow tool into a comprehensive financial operating system that offers lending, issuing, and banking services directly to your users.

The software companies that embrace this evolution will dominate their respective verticals. The ones that don’t will be left behind, competing on software features while their competitors compete on financial infrastructure.

Contact Numus Payments today to discuss your embedded payments strategy.

Our enterprise-grade PFaaS solutions provide the robust APIs, instant onboarding capabilities, and comprehensive risk management tools you need to launch your embedded payments offering quickly and securely. We handle the compliance and the heavy lifting, so you can focus on building great software and growing your revenue.

Chapter 12: The Challenges of Global Embedded Payments

Expanding an embedded payments program globally introduces massive complexity. Software platforms must navigate fragmented regulatory environments (like PSD2 in Europe), integrate dozens of local Alternative Payment Methods (APMs), and manage cross-border payouts and currency conversion, often requiring partnerships with multiple regional acquiring banks or a global orchestration layer.

While embedding payments in a single country (like the US) is challenging, expanding that program globally is an order of magnitude more difficult.

If your SaaS platform has users in the UK, Australia, and Brazil, you cannot simply use your US-based acquiring bank to underwrite and process payments for those international sub-merchants.

The Regulatory Fragmentation

The primary challenge of global embedded payments is regulatory fragmentation.

Every region has its own equivalent of KYC/AML laws, and they are rarely compatible.

  • Europe (PSD2 and SCA): The Payment Services Directive 2 (PSD2) mandates Strong Customer Authentication (SCA) for online transactions. Your embedded checkout flow must support 3D Secure 2.0 to challenge European cardholders with biometric or SMS verification. Furthermore, underwriting European sub-merchants requires complying with GDPR data privacy laws.
  • Latin America: Countries like Brazil have complex tax structures and require specific local entities to process payments. You cannot simply cross-border process a Pix transaction; you need a local acquiring partner.
  • Asia-Pacific: The regulatory landscape varies wildly from highly regulated markets like Singapore to emerging markets with rapidly changing rules.

A software platform attempting to become a global PayFac must essentially build a separate compliance and underwriting department for every major region they enter.

The APM Integration Burden

As discussed in previous chapters, credit cards are not the dominant payment method globally.

If your SaaS platform expands to the Netherlands, your Dutch sub-merchants will demand the ability to accept iDEAL. If you expand to China, they will demand Alipay and WeChat Pay.

Your embedded payment APIs must support the complex redirect flows and asynchronous webhooks required by dozens of different Alternative Payment Methods (APMs).

Cross-Border Payouts and FX

The most complex aspect of global embedded payments is the flow of funds.

Imagine a scenario where a US-based software platform has a sub-merchant in the UK. The UK sub-merchant sells a product to a customer in Japan.

  1. The Japanese customer pays in JPY.
  2. The acquiring bank settles the funds to the US platform’s master account in USD.
  3. The US platform must calculate its fee, convert the remaining USD into GBP, and initiate a cross-border payout to the UK sub-merchant’s bank account.

This process involves multiple currency conversions (Foreign Exchange or FX), each of which incurs a fee. If the platform does not manage these FX rates carefully, the fees will consume their entire processing margin.

Furthermore, cross-border payouts (using networks like SWIFT) are slow, expensive, and prone to failure.

The Global PFaaS Solution

To solve these challenges, software platforms increasingly rely on global PFaaS providers or Payment Orchestration Layers.

These specialized fintech companies have already established the local acquiring relationships, integrated the regional APMs, and built the cross-border payout infrastructure.

By integrating with a single global PFaaS API, the software platform can instantly onboard sub-merchants in 30+ countries, accept 100+ local payment methods, and settle funds in local currencies, abstracting away the massive complexity of global financial regulation.

Chapter 13: The Build vs. Buy Decision for Embedded Payments

The decision to build a custom PayFac infrastructure versus buying a PayFac-as-a-Service (PFaaS) solution depends on the software platform’s processing volume and engineering resources. Platforms processing under $1 billion annually typically choose PFaaS for speed to market, while massive enterprise platforms may build in-house to capture the absolute maximum margin.

Every software platform considering embedded payments faces the classic “Build vs. Buy” dilemma.

Do you invest the time and capital to become a full, registered Payment Facilitator (Build), or do you partner with a PFaaS provider via API (Buy)?

The “Build” Option (Full PayFac)

Pros:

  • Maximum Margin: You keep 100% of the spread between the wholesale Interchange rate and your retail Sell rate.
  • Total Control: You own the entire underwriting process, the risk algorithms, and the flow of funds.
  • Valuation Multiplier: Investors highly value software companies that own their financial infrastructure, often resulting in higher valuation multiples.

Cons:

  • Massive Upfront Cost: Expect to spend $500,000 to $2,000,000 in legal fees, compliance audits, and engineering costs before processing a single transaction.
  • Time to Market: The process of securing an acquiring bank sponsor and building the infrastructure typically takes 12 to 24 months.
  • Absolute Liability: You are financially responsible for every chargeback and fraudulent transaction processed by your sub-merchants.
  • Operational Overhead: You must hire a dedicated team of risk analysts, compliance officers, and payment engineers.

The “Buy” Option (PFaaS)

Pros:

  • Speed to Market: You can integrate the APIs and launch your embedded payment offering in 3 to 6 months.
  • Zero Financial Liability: The PFaaS provider assumes the risk for chargebacks and fraud.
  • Low Upfront Cost: There are typically no massive setup fees or legal costs.
  • Focus on Core Product: Your engineering team can focus on building your software, rather than maintaining complex banking integrations.

Cons:

  • Lower Margin: You must share a portion of the processing spread with the PFaaS provider.
  • Less Control: The PFaaS provider controls the ultimate underwriting decisions. If they deem a sub-merchant too risky, they will decline the account, and you cannot override them.

The Tipping Point

The decision usually comes down to processing volume.

For software platforms processing less than $500 million to $1 billion in annual Gross Merchandise Volume (GMV), the “Buy” (PFaaS) option is almost always the correct choice. The cost and risk of building a full PayFac infrastructure far outweigh the incremental margin gained.

However, once a platform crosses the $1 billion GMV threshold, the economics begin to shift. At that scale, capturing an additional 10 or 20 basis points of margin translates to millions of dollars in pure profit, justifying the investment in an in-house PayFac infrastructure.

Many successful platforms (like Shopify) start with a PFaaS model (partnering with Stripe) to achieve speed to market, and then gradually transition to a full PayFac model as their volume scales into the tens of billions.

Chapter 14: The Impact of Embedded Payments on B2B Transactions

Embedded payments are revolutionizing B2B transactions by replacing slow, manual invoicing and paper checks with automated, digital workflows. Software platforms (like ERPs and accounting tools) embed payment links directly into digital invoices, allowing businesses to pay each other instantly via ACH or commercial credit cards, drastically reducing Days Sales Outstanding (DSO).

While the consumer (B2C) embedded payments revolution is well underway (think Uber or Shopify), the Business-to-Business (B2B) sector is still largely reliant on outdated, manual processes.

A staggering percentage of B2B payments in the United States are still made via paper check.

This creates massive inefficiencies for both the buyer and the supplier.

The Traditional B2B Workflow

  1. A supplier delivers goods to a buyer.
  2. The supplier’s accounting team manually generates an invoice in their ERP system (e.g., NetSuite).
  3. The invoice is printed and mailed, or emailed as a static PDF.
  4. The buyer receives the invoice, manually enters the data into their own accounts payable system, and cuts a paper check.
  5. The check is mailed, received by the supplier, and manually deposited at the bank.
  6. The supplier’s accounting team manually reconciles the payment against the open invoice in their ERP.

This process typically takes 30 to 60 days (Days Sales Outstanding, or DSO), tying up the supplier’s working capital and introducing countless opportunities for human error.

The Embedded B2B Solution

Embedded payments transform this entire workflow into a seamless, digital experience.

When a software platform (like an invoicing tool or an industry-specific ERP) embeds payments, the process looks like this:

  1. The supplier generates a digital invoice within the software platform.
  2. The platform automatically embeds a secure “Pay Now” link directly into the invoice email.
  3. The buyer clicks the link and is taken to a secure, white-labeled payment portal hosted by the software platform.
  4. The buyer pays the invoice instantly using a commercial credit card or an ACH bank transfer.
  5. The funds are routed to the supplier’s account, and the software platform automatically reconciles the payment against the open invoice in real-time.

The Benefits for B2B Platforms

For the software platform providing this embedded infrastructure, the benefits are immense.

  • Massive Transaction Volume: B2B transactions are typically much larger than B2C transactions. While a consumer might spend $50 on a t-shirt, a business might spend $50,000 on a wholesale order. Capturing even a small margin on these massive transactions generates significant revenue.
  • Solving the Reconciliation Nightmare: The primary pain point for B2B accounting teams is reconciliation—matching a lump sum bank deposit to dozens of individual invoices. Because the embedded payment platform controls both the invoice generation and the payment processing, it can automate this reconciliation perfectly, saving the accounting team hundreds of hours per month.
  • Level 2 and Level 3 Processing: B2B transactions often involve commercial or corporate credit cards. These cards carry higher interchange fees unless the merchant provides detailed line-item data (Level 2 and Level 3 data) with the transaction. An embedded payment platform can automatically extract this data from the digital invoice and pass it to the acquiring bank, qualifying the transaction for lower interchange rates and increasing the platform’s processing margin.

The digitization of B2B payments represents a multi-trillion-dollar opportunity for software platforms that successfully embed financial infrastructure into their core products.

Chapter 15: The Importance of Developer Experience (DX) in Embedded Payments

The success of an embedded payments program relies heavily on the Developer Experience (DX) provided by the PFaaS partner. A robust DX includes comprehensive API documentation, pre-built SDKs for frontend integration, clear error handling, and a fully functional sandbox environment, allowing the software platform’s engineering team to build and test the integration quickly and securely.

When a software platform decides to embed payments, the decision is often driven by the executive team (CEO, CFO) based on the business case (revenue, retention).

However, the actual implementation falls squarely on the shoulders of the engineering team.

If the chosen PFaaS provider has a terrible Developer Experience (DX), the integration project will drag on for months, consume massive engineering resources, and ultimately fail to deliver the promised ROI.

The Hallmarks of a Great DX

A world-class PFaaS provider understands that their primary users are developers. They invest heavily in creating tools and resources that make the integration process as frictionless as possible.

  • Comprehensive API Documentation: The documentation must be clear, accurate, and up-to-date. It should include detailed explanations of every endpoint, required parameters, and expected responses. Crucially, it must provide copy-and-paste code snippets in multiple programming languages (e.g., Node.js, Python, Ruby, Java).
  • Pre-Built SDKs and Libraries: Developers should not have to write raw HTTP requests to interact with the API. The provider should offer official SDKs that abstract away the complexity of authentication, error handling, and data formatting.
  • Frontend UI Components: To maintain PCI SAQ A compliance, the software platform must use the provider’s secure IFrames to collect credit card data. The provider should offer highly customizable, pre-built UI components (like Stripe Elements) that seamlessly blend into the platform’s existing design system.
  • Clear Error Handling: When an API request fails (e.g., a declined transaction or a missing parameter), the API must return a clear, actionable error message. Vague errors like “500 Internal Server Error” are unacceptable. The error should specify exactly what went wrong (e.g., “Invalid CVV”) so the developer can build appropriate exception handling into their application.
  • A Fully Functional Sandbox: Developers need a safe environment to build and test their integration without moving real money. The sandbox must perfectly mirror the production environment, allowing developers to simulate every possible scenario, including successful charges, declined cards, chargebacks, and complex split payouts. By prioritizing Developer Experience, PFaaS providers empower software platforms to launch their embedded payment offerings faster, with fewer bugs, and a significantly lower total cost of ownership.