How SaaS and ISV Companies Can Add Payment Processing to Their Software

What embedded payment processing means for your software business

Embedded payment processing means building the ability to accept and process payments directly into your software platform, rather than sending customers elsewhere to pay. Instead of redirecting a user to a separate payment page, the transaction happens inside your application—on your website, in your mobile app, or through your API.

For SaaS and ISV companies, this matters because it changes how customers experience your product. A user managing a project in your software can pay an invoice without leaving it. A contractor using your platform can collect deposits without a separate checkout link. The payment becomes part of your workflow, not an interruption to it.

The trade-off is that you become responsible for security, compliance, and the technical work of connecting to payment networks. You are not processing the money yourself—a payment processor or acquiring bank does that—but you are the interface between your customer and the payment system.

Key Takeaways

• Embedded payments require you to integrate with a payment processor's API and meet PCI compliance standards, which means storing or handling payment data securely or using a processor that handles it for you.
• The three main routes are payment APIs (Stripe, Square, PayPal), white-label solutions (Adyen, Worldpay), and custom acquiring relationships with a bank, each with different costs and control levels.
• Revenue share models typically run 2.2% to 3.5% per transaction plus per-transaction fees, though volume discounts and custom rates are common for SaaS companies processing significant monthly volume.
• You will need to document your payment flow, prove your security practices, and often sign a contract with both a payment processor and an acquiring bank before going live.
• Choosing between hosted payment forms, API-based integration, and tokenization depends on how much control you want over the user experience and how much security responsibility you can take on.

Payment APIs versus white-label processors versus direct acquiring

The three main paths differ in how much control you have, how much technical work you do, and what you pay.

Payment APIs (Stripe Connect, Square, PayPal Commerce Platform) are the fastest route for most SaaS companies. You integrate their API into your software, they handle the security and compliance, and you pay a percentage of each transaction plus a per-transaction fee. You control the look and feel of the payment form within your app, but the processor owns the relationship with the payment networks and the acquiring bank. This is the lowest-friction option and requires the least legal setup.

White-label processors (Adyen for Platforms, Worldpay for Platforms, Fiserv) let you brand the payment experience as your own and often give you more control over pricing and customer data. You still integrate an API, but the processor works more like a partner than a vendor. These are typically used by larger SaaS companies or ISVs that process millions per month and want to offer their own payment terms to customers. Setup takes longer and costs more upfront, but per-transaction fees can be lower at scale.

Direct acquiring relationships mean you contract directly with an acquiring bank (like JPMorgan Chase, Bank of America, or a smaller acquirer) and handle payment processing through their systems or a processor they recommend. This gives you the most control and potentially the lowest costs, but it requires you to manage PCI compliance yourself, sign multiple contracts, and often maintain higher reserve balances. Most SaaS companies do not pursue this route unless they are processing tens of millions per year.

How PCI compliance affects your integration choices

PCI DSS (Payment Card Industry Data Security Standard) is a set of security rules that apply to anyone who handles credit card data. The level of compliance you need depends on how you handle that data.

If you use a hosted payment form (the processor's form embedded in your page, or a redirect to the processor's page), you handle almost no card data yourself—the processor does. You are PCI Level 3 or 4, the lowest burden. You still need a basic security audit and a firewall, but you do not need to encrypt card data or maintain a secure server environment for payment information.

If you build your own payment form and send the card data to the processor's API, you are handling raw card data in transit. You move to PCI Level 2, which requires annual security audits, encryption, and documented security practices. Many payment processors offer tokenization to avoid this: your form collects the card, you send it directly to the processor (not through your server), the processor returns a token, and you store only the token. This keeps you at Level 3 or 4.

If you store card data on your own servers—even encrypted—you are PCI Level 1, the highest burden. You need quarterly security audits, penetration testing, and a dedicated security team. Almost no SaaS company does this. Instead, they use tokenization or a payment processor that stores the card data for them.

Pricing models and what volume discounts look like

Most payment processors charge a percentage of the transaction (the interchange rate, typically 1.5% to 2.9% depending on card type) plus a per-transaction fee (usually $0.20 to $0.30). On top of that, they add their own markup: another 0.5% to 1.5% plus $0.10 to $0.20 per transaction. The total for a typical credit card transaction is 2.2% to 3.5% plus the per-transaction fee.

For SaaS companies, volume matters. If you process $10,000 per month, you pay the standard rate. If you process $100,000 per month, most processors will negotiate. At $1 million per month, you can often get rates down to 1.8% to 2.2% plus lower per-transaction fees, or even a flat monthly fee plus a lower percentage. White-label processors and direct acquiring relationships offer better rates at scale, but the setup costs and legal work are higher.

Some processors also charge monthly fees ($20 to $100) for access to their platform, or charge for specific features like recurring billing, international payments, or advanced reporting. Read the contract carefully—the percentage and per-transaction fee are not the only costs.

Integration methods: hosted forms, APIs, and tokenization

Once you choose a processor, you decide how to integrate it into your software. The three main methods trade off between ease and control.

Hosted payment forms are the simplest. You redirect the user to the processor's page (or embed their form in an iframe), they enter their card, and the processor sends the result back to you. You handle almost no card data. The downside is that the user leaves your interface, which can hurt conversion rates. Most processors let you customize colors and logos, but the form is not fully yours.

API-based integration means you build your own payment form, collect the card data, and send it to the processor's API. You control the entire experience and keep the user in your app. The downside is that you handle card data in transit, which raises your PCI level. Most processors offer tokenization to mitigate this: your form sends the card directly to the processor (bypassing your server), the processor returns a token, and you store the token instead of the card.

Tokenization is the middle ground. The user enters their card in your form, but the data goes directly to the processor's secure server, not through your application. The processor returns a token—a unique identifier for that card—which you store and use for future charges. This keeps your PCI burden low while giving you full control over the user experience.

What you need before you can go live

Before a processor will let you accept payments, you will need to provide documentation and sign contracts. The exact requirements vary by processor, but the pattern is the same.

First, you will need to document your payment flow: how you collect payment information, where it goes, how you store it, and how you use it. This is usually a diagram or a written description. The processor uses this to assess your security practices and your PCI level.

Second, you will need proof of your business: articles of incorporation, a business license, tax ID, and the names and addresses of owners. If you are a new company, some processors will ask for a personal may provide from the founder.

Third, you will need a contract with the processor. This spells out the fees, the terms of service, what happens if you violate PCI rules, and what the processor can do if chargebacks or fraud spike. Read this carefully—it often includes clauses about reserve balances (money the processor holds in case of chargebacks) and termination rights.

Fourth, if you are using a white-label processor or pursuing direct acquiring, you will also need a contract with an acquiring bank. This is separate from the processor contract and is more formal. The bank underwrites your business, sets your reserve balance, and has the final say on whether you can process payments.

Handling chargebacks, disputes, and customer refunds

Once you are processing payments, you will encounter chargebacks—when a customer disputes a charge with their card issuer. The card issuer pulls the money back from your processor, and you lose the payment plus a chargeback fee (usually $15 to $100 per dispute).

You can dispute a chargeback by providing evidence: an order confirmation, a shipping receipt, a signed contract, or proof that the customer received the service. The processor gives you a window (usually 7 to 10 days) to submit evidence. If the card issuer agrees with you, you get the money back. If not, you lose it.

High chargeback rates (usually above 0.5% to 1% of your transaction volume) can trigger a processor to freeze your account or terminate your contract. Some processors require you to maintain a reserve balance—money held in an account—to cover potential chargebacks. The reserve is usually 5% to 25% of your monthly volume, and it can take months to get it back after you close your account.

Refunds are simpler: you initiate a refund through the processor's dashboard, and the money goes back to the customer's card. Most processors process refunds within 1 to 3 business days, though the customer's bank may take longer to post it.

Recurring billing and subscription payments

If your SaaS product charges on a subscription basis, you will need to store payment information and charge it repeatedly. This requires a processor that supports recurring billing and a way to securely store and reuse payment tokens.

Most payment APIs (Stripe, Square, PayPal) have built-in recurring billing features. You create a subscription in their dashboard or API, set the amount and frequency, and the processor charges the customer automatically on the schedule you define. If a charge fails (card expired, insufficient funds), the processor retries it a few times and notifies you.

You will need to handle failed charges gracefully: send the customer a notification, give them a way to update their payment method, and decide whether to suspend their access or keep it active while they fix the payment. Most SaaS companies suspend access after 3 to 5 failed attempts over a few weeks.

Recurring billing also means you need to comply with regulations around billing authorization. In the US, the ROSCA rule requires you to get clear, affirmative consent before charging, make it easy for customers to cancel, and send a reminder before each charge. Different countries have different rules—the EU's PSD2 requires strong customer authentication for recurring payments, which adds complexity.

Frequently Asked Questions

Can I use multiple payment processors at once?

Yes, many SaaS companies do. You might use Stripe for credit cards and PayPal for PayPal customers, or use one processor for US payments and another for international. The downside is that you manage multiple contracts, multiple integrations, and multiple sets of fees. Most companies start with one processor and add others only if the first cannot meet their needs.

What happens if a payment processor shuts down my account?

If a processor terminates your account, you lose the ability to process new payments immediately. You will have a window (usually 30 to 90 days) to retrieve your customer data and switch to a new processor. You should have a backup processor ready or a plan to migrate quickly. This is rare for legitimate businesses but common for high-risk industries like gambling or adult content.

Do I need a separate merchant account?

If you use a payment API like Stripe or Square, no—they provide the merchant account as part of their service. If you pursue direct acquiring or a white-label processor, you will need a separate merchant account from an acquiring bank. The processor or bank will set this up for you, but you are responsible for maintaining it.

How do I handle payments in multiple currencies?

Most payment processors support multi-currency processing. You set prices in different currencies, and the processor handles the currency conversion and settlement. Conversion fees are usually 1% to 3% on top of your normal processing fees. Some processors settle in your home currency, others let you hold balances in multiple currencies. Check the contract to understand how conversion and settlement work.

What if my customers are outside the US?

Most US-based payment processors support international cards and customers. However, some countries have restrictions on which processors can operate there, and some processors charge higher fees for international transactions. If you have significant volume from a specific country, ask the processor about local payment methods (like iDEAL in the Netherlands or Alipay in China) and whether they support them. White-label processors and direct acquiring relationships often have better international support.