# How to Build a Payment Processor: Build vs Buy Guide

> How to build a payment processor, what it really takes (bank sponsorship, PCI DSS Level 1, licensing), and when a PayFac, processor API, or MoR is the smarter path.
- **Author**: Ayush Agarwal
- **Published**: 2026-10-18
- **Category**: Payments, Engineering
- **URL**: https://dodopayments.com/blogs/en/how-to-build-a-payment-processor

---

To build a payment processor, you need a sponsoring acquiring bank, direct or sponsored registration with the card networks, a PCI DSS Level 1 certified environment for card data, a risk and fraud engine, settlement and reconciliation systems, a disputes pipeline, and the licenses required in every market where you move money. Realistically that is a multi-year, heavily regulated project, which is why most software companies instead build on a processor's API, become a payment facilitator (PayFac), or use a Merchant of Record. The right choice depends on whether payments are your product or just how you get paid.

I get some version of this question from technical founders every few weeks. Usually it starts with a fee comparison spreadsheet and a thought like "it's just an API call to Visa, how hard can it be?" We built Dodo Payments, so I have lived the answer. The API call is the easy part. The bank relationships, audits, money movement, tax, and liability around that call are where the years go.

This guide breaks down what a payment processor actually is, every component you would have to build, the four realistic paths, and an honest build vs buy framework for SaaS, AI, and digital product companies.

## What a Payment Processor Actually Is (and What It Is Not)

People use "payment processor," "payment gateway," and "payment provider" interchangeably, and that confusion is the root of most bad build decisions. A processor is the entity that moves transaction data between the merchant side and the card networks, handles authorization and clearing messages, and works with an acquiring bank to settle funds. A gateway is the front door that captures payment details and passes them to the processor. If you want the long version, we covered it in [payment gateway vs payment processor](https://dodopayments.com/blogs/payment-gateway-vs-payment-processor).

Here is how the main roles compare:

| Role | What it does | Holds merchant liability? | Legal seller to the customer? | Typical builder |
| --- | --- | --- | --- | --- |
| Payment gateway | Captures card details, encrypts and forwards them to a processor | No | No | Software companies, PSPs |
| Payment processor | Routes authorization and clearing between merchant side and card networks | Shares with acquirer | No | Large fintechs, bank-owned processors |
| Acquiring bank | Holds the merchant relationship, sponsors network access, settles funds | Yes, ultimately | No | Licensed banks |
| Payment facilitator (PayFac) | Onboards sub-merchants under its own master merchant account | Yes, for its sub-merchants | No, each sub-merchant is | Vertical SaaS platforms |
| Merchant of Record (MoR) | Resells your product, processes payments, handles tax and compliance | Yes | Yes | Dodo Payments and similar platforms |

The acquiring bank row is the one most founders skip. Card networks do not let a startup plug in directly. You get access through a licensed bank that sponsors you, and that bank holds the ultimate risk. The split between that bank and the cardholder's bank is explained in [acquiring bank vs issuing bank](https://dodopayments.com/blogs/acquiring-bank-vs-issuing-bank).

### How a card payment flows

Every card payment runs two loops: authorization in real time, then clearing and settlement later. This is the path a processor sits in the middle of:

```mermaid
flowchart LR
    A["Customer"] -->|"Card details"| B["Gateway / API"]
    B -->|"Auth request"| C["Processor"]
    C -->|"Routes by card brand"| D["Card network (Visa, Mastercard)"]
    D -->|"Approve or decline?"| E["Issuing bank"]
    E -->|"Auth response"| D
    D -->|"Response"| C
    C -->|"Result"| B
    B -->|"Success or failure"| A
    C -.->|"Clearing and settlement via acquirer"| F["Merchant bank account"]
```

The authorization round trip has to complete within a few seconds, at scale, with near-perfect uptime. Settlement then happens in batches, where the acquirer receives funds from the network, deducts fees such as interchange (see [interchange fees explained](https://dodopayments.com/blogs/interchange-fees-explained)), and pays the merchant.

## The Components You Need to Build Your Own Payment Gateway and Processor

If you decide to build your own payment gateway and processing stack, this is the minimum bill of materials. None of these are optional if you touch card data and move money.

### 1. Gateway and merchant-facing API

This is the part engineers picture: endpoints to create payments, capture, refund, and send webhooks. You also need hosted checkout or client-side SDKs so merchants never handle raw card numbers. The hosted vs embedded decision alone changes your compliance scope, which we break down in [hosted vs self-hosted payment gateways](https://dodopayments.com/blogs/hosted-vs-self-hosted-payment-gateway).

### 2. Tokenization vault

Raw card numbers (PANs) must be replaced with tokens the moment they enter your system. The vault that maps tokens back to PANs is the most sensitive system you will ever run: isolated network segment, hardware security modules for key management, strict access controls, and full audit logging. Our primer on [payment tokenization](https://dodopayments.com/blogs/payment-tokenization) covers the mechanics. Mature processors also act as token requestors with the card networks, so stored cards survive reissues, which is the subject of our guide to [network tokenization](https://dodopayments.com/blogs/network-tokenization).

### 3. PCI DSS Level 1 scope

As a processor or gateway you are a service provider under PCI DSS, and at any meaningful volume you will be assessed at Level 1. That means an annual assessment by a Qualified Security Assessor, quarterly external vulnerability scans, penetration testing, and documented controls across every system that stores, processes, or transmits card data. It is a continuous program with dedicated compliance staff, not a one-time certificate. If you only want card access through another processor, the scope trade-offs are explained in [raw card API and PCI compliance](https://dodopayments.com/blogs/raw-card-api-pci-compliance).

### 4. Acquiring bank sponsorship

You need a bank willing to sponsor you into the card networks. Banks underwrite you as they would a lender: capitalization, ownership, management experience, risk controls, and compliance programs. Expect extensive due diligence, reserve requirements, and ongoing oversight. Many otherwise good fintech plans stall here.

### 5. Card network registration

With a sponsor in place, you register with each card network in the role you are taking (for example, as a third-party processor or service provider) and agree to follow their operating rules. Those rules govern everything from descriptor formats to dispute timelines to data security, and they change regularly. Each network is a separate relationship.

### 6. Risk and fraud

A processor carries the losses when a merchant disappears with customer money or gets hit with fraud it cannot cover. You need merchant underwriting and KYC/KYB, transaction monitoring, velocity checks, 3D Secure, and models that catch patterns like card testing fraud before they trigger network fines or excessive chargeback programs.

### 7. Settlement and reconciliation

Every day you receive settlement files from networks and acquirers, match them against your own ledger, calculate fees, and move money to merchants. The ledger must be double-entry and immutable. Off-by-one-cent errors compound into real liabilities. Even on the merchant side, [payment reconciliation](https://dodopayments.com/blogs/payment-reconciliation-saas) is a discipline of its own.

### 8. Disputes and chargebacks

Chargebacks arrive through network systems with strict response deadlines. You need intake, evidence collection, representment workflows, and monitoring of merchant dispute ratios against network thresholds. If the concept is new, start with [what a chargeback is](https://dodopayments.com/blogs/what-is-a-chargeback-explained).

### 9. Payouts

Funds must reach merchants on schedule, in their currency, through domestic rails or cross-border transfers. That means banking partners in each payout corridor, FX handling, and sanctions screening on every recipient.

### 10. Licensing

In the US, holding or transmitting funds on behalf of others generally triggers money transmitter licensing, which is regulated state by state, plus federal registration and anti-money-laundering obligations. The EU, UK, India, and other markets each have their own payment institution or e-money regimes. Some structures (like processing strictly as an agent of a bank) can narrow what you need, but that is a legal question for specialized counsel in each jurisdiction.

### 11. Tax, if you sell globally

A processor does not owe tax on your merchants' sales. But if your actual goal is selling your own software worldwide, building a processor solves none of your sales tax, VAT, and GST obligations. You would still need to register, collect, and file in each jurisdiction where you cross a threshold, as covered in [when SaaS companies must collect sales tax](https://dodopayments.com/blogs/sales-tax-nexus-saas-when-to-collect).

## Build vs Buy Payments: The Four Realistic Paths

Once you see the full list, the question shifts from "how do I build a payment processor" to "how much of this stack do I actually need to own?" There are four realistic answers.

| Path | What you own | Typical time to launch | Main ongoing cost | Who it fits |
| --- | --- | --- | --- | --- |
| 1. Become a processor | Everything: bank sponsorship, network registration, PCI Level 1, licensing, risk | Typically years | Audits, compliance and risk teams, capital reserves | Funded fintechs where processing is the product |
| 2. Become a PayFac | Sub-merchant onboarding, underwriting, risk, payouts, liability | Typically many months to over a year | Underwriting and risk staff, losses from sub-merchants | Vertical SaaS monetizing payments for its customers |
| 3. Build on a processor API | Your integration, your tax, your compliance as seller | Days to weeks to integrate, longer for tax and compliance | Processing fees plus tax and finance operations | Companies with in-house finance and tax capability |
| 4. Use a Merchant of Record | Your product and checkout experience | Days | One bundled fee per transaction | SaaS, AI, and digital product companies selling globally |

### Path 1: Become a payment processor

This is the full build. You raise significant capital, hire payments, risk, and compliance leaders, secure an acquiring bank sponsor, register with networks, pass a PCI DSS Level 1 assessment, obtain licenses, and build every component listed above. It is typically measured in years before you process meaningful volume, and the ongoing cost is dominated by people: auditors, compliance staff, risk analysts, and banking operations.

It makes sense when processing itself is the business, you have a distribution advantage that will route large volume through you, and you can carry the capital and liability.

### Path 2: Become a payment facilitator

A PayFac sits between a processor and many small merchants. You get a master merchant account through a sponsor bank and processor, then onboard your own customers as sub-merchants. You take on their underwriting and their losses, but you can capture part of the processing margin. We compared this model directly with MoR in [merchant of record vs PayFac](https://dodopayments.com/blogs/merchant-of-record-vs-payfac).

The PayFac route is popular with vertical SaaS (think software for gyms, clinics, or marketplaces) where payments are a revenue line. It is the wrong tool if you are a SaaS company that only needs to get paid for your own subscriptions.

### Path 3: Build on a processor API

This is what most startups mean when they say they "built payments." You integrate a processor's API, keep card data out of your servers with hosted fields or checkout, and own everything above the transaction. Processing is solved. What remains is yours: being the legal seller, sales tax and VAT registration and filing, chargeback management, local payment methods, and invoicing.

Teams that grow on this path often add a routing layer across multiple processors later. If that is where you are headed, read about [payment orchestration](https://dodopayments.com/blogs/payment-orchestration) and [smart payment routing](https://dodopayments.com/blogs/smart-payment-routing) before you write your own.

### Path 4: Use a Merchant of Record

A Merchant of Record becomes the legal seller of your product. It processes the payment, calculates and remits tax, handles fraud screening and dispute tooling, and pays you out. You keep the product and customer relationship while offloading the regulated parts. If the model is unfamiliar, see [what a merchant of record is](https://dodopayments.com/blogs/what-is-a-merchant-of-record).

For a SaaS or AI company selling to customers in many countries, this removes nearly every item on the component list from your roadmap, including the tax work that a processor never solves.

## Payment Processing Infrastructure: When Building Makes Sense and When It Does Not

Here is the framework I use when founders ask whether to build payment processing infrastructure in-house.

Building your own processor or PayFac makes sense when:

- Payments revenue is a core part of your business model, not a cost center
- You expect large, predictable volume that justifies fixed compliance costs
- You can raise capital specifically for reserves, licensing, and a compliance team
- You have, or can hire, leaders who have run PCI Level 1 programs and bank partnerships before
- Your merchants need something existing processors genuinely cannot offer

Building does not make sense when:

- You are a SaaS, AI, or digital product company and payments are how you collect revenue
- Your motivation is mainly shaving fees, since interchange and network assessments are pass-through costs you pay regardless of who processes
- Your engineering team is small and every quarter spent on compliance is a quarter not spent on product
- You sell globally and the harder problem is tax, local methods, and chargebacks rather than authorization

That fee point deserves emphasis. Interchange goes to the issuing bank and network fees go to the networks no matter who processes. Building a processor only lets you eliminate the processor's markup, while adding the full fixed cost of running one. For most companies the math does not close until volume is very large.

A middle option many teams overlook is a [white-label payment gateway](https://dodopayments.com/blogs/white-label-payment-gateway), which gives you a branded payments product without owning the processing core.

## How Dodo Payments Fits

We built Dodo Payments so that software companies can skip the processor build entirely. Dodo acts as your Merchant of Record: the legal seller that handles sales tax, VAT, and GST, compliance, and chargebacks. The platform is PCI DSS Level 1, card numbers are tokenized on entry with fraud scoring, CVV validation, and 3D Secure, and checkout supports 40+ payment methods and 80+ currencies across 220+ countries and territories.

Integration is a single API call to create a hosted checkout session. Card data never touches your servers, which keeps your own PCI scope minimal:

```ts
import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env['DODO_PAYMENTS_API_KEY'],
});

const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: 'pdt_123', quantity: 1 }],
  return_url: `${process.env['APP_URL']}/checkout/success`,
});

// Redirect the customer to the hosted, PCI-compliant checkout
console.log(session.checkout_url);
```

The full request options (customer details, billing currency, allowed payment methods) are in the [checkout sessions guide](https://docs.dodopayments.com/developer-resources/checkout-session), and the [Node and other SDKs](https://docs.dodopayments.com/developer-resources/dodo-payments-sdks) are documented separately. Payment status changes arrive through [webhooks](https://docs.dodopayments.com/developer-resources/webhooks), so your fulfillment logic stays event-driven.

If you already have a processor relationship, you do not have to give it up. With [Bring Your Own Processor](https://docs.dodopayments.com/features/byop), you connect your own Stripe or Adyen account and route payments from chosen countries through it, while Dodo runs products, subscriptions, invoicing, the customer portal, and analytics on top. BYOP is priced at 0.5%. The trade-off is honest: on BYOP routes you are the legal seller, so you handle tax and disputes in your processor, and those routes currently support cards only. A common setup is hybrid, with your home market on your own processor and the rest of the world on Dodo as Merchant of Record.

On the full MoR model, pricing starts at 4% + 40c for domestic US cards and wallets, with an additional 1.5% for international cards and methods, no monthly fees, and tax management included. The details are on the [Dodo Payments pricing page](https://dodopayments.com/pricing).

## FAQ

### How long does it take to build a payment processor from scratch?

Typically years rather than months. Engineering the gateway is the quick part, while securing an acquiring bank sponsor, registering with card networks, passing a PCI DSS Level 1 assessment, and obtaining licenses in each market drive most of the timeline.

### Can a startup connect directly to Visa or Mastercard?

Not directly in the way most founders imagine. Card network access runs through a licensed acquiring bank that sponsors you, and you must register with each network and follow its operating rules.

### Do I need a money transmitter license to process payments?

In the US, holding or moving funds on behalf of others generally requires state money transmitter licenses, though some structures operating as an agent of a bank may narrow that requirement. Requirements vary by state and country, so this needs specialized legal advice before you build.

### Is becoming a payment facilitator cheaper than using a merchant of record?

A PayFac can earn a share of processing margin, but it takes on sub-merchant underwriting, losses, and compliance costs, and it does not handle your sales tax obligations. For a company selling its own software, a Merchant of Record is usually simpler and avoids those fixed costs.

### Can I keep my existing Stripe or Adyen account and still use a merchant of record?

Yes, with Dodo Payments' Bring Your Own Processor option you route selected countries through your own Stripe or Adyen account and send the rest through Dodo as Merchant of Record. On your own processor routes you remain the legal seller and handle tax and disputes yourself.

## Final Thoughts

Learning how to build a payment processor is worth it even if you never build one, because it shows you exactly which risks you are paying someone else to carry. Bank sponsorship, network rules, PCI DSS Level 1, licensing, settlement, and disputes are each serious programs, and tax sits on top for anyone selling globally.

If payments are your product, the processor or PayFac path can be the right long-term bet. If payments are how your SaaS or AI product gets paid, put that engineering time into the product and let a Merchant of Record handle the stack. You can see how [Dodo Payments](https://dodopayments.com) handles it end to end, from checkout to tax to payouts.
---
- [More Payments articles](https://dodopayments.com/blogs/category/payments)
- [All articles](https://dodopayments.com/blogs)