How to Become a Payment Processor in 2026
A 2026 playbook for launching a payment processing company: processor vs acquirer vs PSP vs PayFac vs gateway, licensing, PCI DSS Level 1, network principal membership, unit economics and tech stack.
What a payment processor actually does
A payment processor is the company that moves a card authorisation message between the merchant and the issuing bank, then pulls the funds back through settlement. Every time a card is tapped, dipped or typed into a checkout, a processor is doing the technical heavy lifting behind the scenes: routing the ISO 8583 or ISO 20022 message, applying fraud rules, communicating with the card networks, and returning an approval in under a second.
Becoming a payment processor in 2026 is very different from becoming one in 2016. Card volumes keep compounding (global card payments crossed 600 billion transactions a year), but so does the regulatory perimeter: PSD3, DORA, PCI DSS v4.0.1, the EU Instant Payments Regulation and stricter network oversight all shape what you have to build. The good news is that the stack is now modular. You no longer need to own a switch, a HSM farm and a settlement engine from day one. You can rent or build each layer.
Authorisation
Receive the transaction from the merchant, route it to the right network, and return an approve or decline in milliseconds.
Clearing
Aggregate the day's authorised transactions and exchange files with Visa, Mastercard and domestic schemes.
Settlement
Pull funds from issuers, net interchange and scheme fees, and pay the merchant on the agreed cycle.
If you only remember one thing: a processor is a message router and a money mover. Everything else (risk, reporting, tokenisation, reconciliation) is an accessory on top of those two core jobs.
Let's discuss your project and see how we can launch your digital banking product together
Request demoProcessor vs acquirer vs PSP vs PayFac vs gateway
These five labels are used interchangeably in pitch decks, which is a problem because they describe different legal entities with different licences, different economics and different liability. Here is the practical split.
| Role | What it does | Licence or membership | Who holds the merchant contract |
|---|---|---|---|
| Acquirer | Holds funds for merchants, takes on credit and chargeback risk, signs the merchant agreement. | Bank or Payment Institution plus Visa or Mastercard principal membership. | Acquirer itself. |
| Processor | Runs the technical switch: authorisation, clearing, settlement files, tokenisation. | Usually no financial licence, but PCI DSS Level 1 and scheme certification required. | No direct contract; serves the acquirer. |
| PSP (gateway plus) | Bundles a gateway, fraud tools and an acquirer relationship into one commercial product. | Typically a Payment Institution licence for fund flows (Stripe, Adyen, Checkout.com). | PSP or a partner acquirer. |
| PayFac | Onboards sub-merchants under its master MID, runs KYB and risk, pays sub-merchants directly. | Registered PayFac with a sponsor acquirer; PI licence if holding funds. | PayFac contracts the merchant, acquirer contracts the PayFac. |
| Gateway | Pure tech layer: accepts the transaction from the checkout, encrypts, forwards to the processor. | No licence, PCI DSS required. | None. |
The biggest commercial decision you make at the start is which of these you want to be. A pure processor is a B2B infrastructure business with fat margins and long sales cycles. A PayFac is a vertical SaaS play where payments is a revenue multiplier. A PSP is the most crowded (and most capital-hungry) slot. Pick one and build for it.
Roles in a card transaction
Seven parties touch every card transaction. Understanding the choreography tells you where your processor fits, where the fees get taken, and where the liability sits when a chargeback lands.
Cardholder
Presents a card at the merchant checkout, online or at POS.
Merchant & gateway
Checkout captures card data, gateway tokenises and forwards.
Acquirer & processor
Receive the auth request, run risk checks, forward to the network.
Network & issuer
Visa or Mastercard routes to the issuer, which approves or declines.
The return path mirrors the request, typically finishing in 300 to 800 milliseconds. Settlement happens later, usually T+1 or T+2, when the acquirer pulls funds from the issuer via the network, subtracts interchange and scheme fees, and pays the merchant. As a processor you live inside step three, handling the message plumbing and eventually the clearing and settlement files.
Which model to pick: acquiring, PayFac, ISO or gateway-only
There are four honest routes into the industry in 2026. Each has a different cost, a different time-to-market and a different regulatory ceiling.
Merchant acquiring
Full PI or bank licence plus Visa or Mastercard principal membership. You hold the MID, you carry the risk, you keep the biggest share of the economics.
Capital: €10-50M. Time: 18-36 months. Best for: well-funded teams with a real merchant book.
Payment Facilitator (PayFac)
Sign one master agreement with a sponsor acquirer, then onboard sub-merchants yourself under a simplified KYB flow. You own the merchant experience and share revenue with the sponsor.
Capital: €1-3M. Time: 6-12 months. Best for: vertical SaaS platforms (marketplaces, bookings, SMB tools).
ISO or reseller
Sell an acquirer's or PSP's product under your brand. Minimal tech build, recurring residuals on volume, no licence needed. A good way to test demand before investing in infrastructure.
Capital: €100-500k. Time: 1-3 months. Best for: sales-led founders in a specific vertical or region.
Gateway-only
Build the checkout, tokenisation, 3DS and fraud layer without touching funds. Pair with any acquirer. Low regulatory burden, but you compete with Stripe and Adyen on UX and reliability.
Capital: €0.5-2M. Time: 4-9 months. Best for: tech-heavy teams with a niche (crypto on-ramp, high-risk, regional).
Most successful 2026 launches start as a PayFac or ISO in one vertical, accumulate volume, and only then apply for their own licence and principal membership. Trying to do full acquiring from day one usually burns capital faster than it wins merchants.
Licensing and network principal membership
The regulatory stack is layered. You need the right financial licence for the money flows, the right network status for card scheme participation, and a set of operational certifications to plug into either.
- Financial licence. In the EU, a Payment Institution (PI) authorisation under PSD2 (and soon PSD3) covers acquiring. An Electronic Money Institution (EMI) adds the ability to issue e-money and cards. A full banking licence adds deposits and lending. Choose the lightest option that fits the money flows you actually run. Capital requirements range from €125k for a PI to €5M for a bank, plus ongoing own-funds obligations.
- Visa and Mastercard principal membership. To acquire directly you apply for Principal Member status. Expect a six to twelve month review, scheme fees (tens of thousands of euros per year), and strict BIN sponsorship rules. Affiliate or sponsored membership is faster but caps your independence.
- PCI DSS Level 1. Any entity that stores, processes or transmits more than six million card transactions per year has to be PCI DSS Level 1 under v4.0.1 (in force from April 2025). Expect a six-month implementation and an annual Report on Compliance by a QSA. This is non-negotiable.
- Fraud and chargeback tooling. 3DS2, network tokenisation, device intelligence and behavioural scoring are table stakes. You also need a dispute workflow aligned with Visa VCR and Mastercard MCOP timelines.
- Underwriting and AML. Every merchant or sub-merchant must be underwritten (KYB, sanctions, PEP, business model risk). You need a live transaction monitoring engine, SAR reporting, and in the EU a compliance officer registered with the regulator.
None of this is optional. The 2023-2025 wave of enforcement actions (US OCC consent orders, BaFin measures on German EMIs, FCA focus on UK PIs) made the cost of a weak compliance programme painfully high.
A realistic roadmap: niche to live traffic
The fastest teams run a sequence that looks roughly like this.
Niche & jurisdiction
Pick one vertical (SaaS billing, travel, B2B marketplace). Choose a regulator whose timeline and track record fit your plan. Lock in seed capital.
Licence & sponsor
File the PI or EMI application, or sign a sponsor acquirer if you start as a PayFac. Draft the AML, safeguarding and outsourcing policies.
Tech & PCI
Build or buy the gateway, ledger, tokenisation, 3DS2 and fraud engine. Start PCI DSS Level 1 work in parallel with licensing.
Scheme certification
Complete Visa VCMS and Mastercard MTF certifications. Integrate with the networks' directories, tokenisation and dispute APIs.
Pilot merchants
Onboard five to twenty friendly merchants, run real traffic, tune risk and chargeback flows, close the first audit cycle.
Scale & new corridors
Expand to additional countries, add alternative payment methods (Bizum, Swish, PIX), plan for principal membership if you started sponsored.
The teams that slip the most are the ones that try to build the switch, the ledger and the scheme integrations from scratch in parallel with the licence application. Pick your build-versus-buy boundary early and stick with it.
Tech stack: build, buy or combine
You have three realistic tech choices. Most teams mix them.
| Option | What you get | Trade-off |
|---|---|---|
| Legacy processors (Fiserv, TSYS, Worldpay, Global Payments) | Battle-tested switch, global scheme connectivity, mature dispute and clearing modules. The engine room behind most banks and large acquirers. | Long integration cycles, high minimums, older developer experience. Good fit if you have scale from day one. |
| Modern issuing and acquiring platforms (Nuvei, Checkout.com, Adyen for Platforms, Marqeta) | Cleaner APIs, faster onboarding, ready-made PayFac tooling, global acquiring in one contract. | Less flexibility deep in the stack, higher per-transaction cost, you are a tenant on their infrastructure. |
| Build on BaaS plus white-label (Crassula, Solaris, Swan, ClearBank) | Branded product, your own ledger and admin console, modular swap of acquirer or issuer. Ships in weeks rather than years. | You still need a sponsor or your own licence. You own risk, fraud and support. |
A common 2026 pattern: Crassula (or similar) for the product layer and ledger, a PSP or acquirer for the scheme connection, and a specialist for fraud (Riskified, Ravelin, Featurespace). The more cleanly these pieces are separated, the easier it is to swap one out without a rewrite.
Unit economics: where the money really is
Card processing looks like a great business at first glance. The fine print is in the fee stack. A typical European card-present transaction at 1.5% merchant discount rate breaks down roughly as follows.
In Europe, interchange is capped under the Interchange Fee Regulation: 0.2% for consumer debit and 0.3% for consumer credit. Commercial cards, cross-border and inter-regional flows sit above the cap. In the US, Durbin-regulated debit is around 0.05% plus $0.22 per transaction, while credit and small-bank debit (Durbin-exempt) run around 1.5%. Your processor and acquirer margin lives on top of these, typically 20 to 80 basis points, and is eaten by fraud, chargebacks, PCI, compliance headcount and scheme fines.
The takeaway: gross volume is vanity, net take rate is reality. Model the fee stack transaction by transaction, per corridor and per card product, before you sign a single merchant.
How Crassula helps you launch a payment processor
Crassula is the white-label core that sits between your licensed entity (or sponsor acquirer) and your merchants. You get the product, the ledger and the back office. You keep the brand, the pricing and the merchant relationships.
Modular core
Ledger, IBAN and card issuing, acquiring orchestration, FX, dispute workflows and reconciliation. Plug in your acquirer of choice (Nuvei, Checkout.com, a local bank) or your own principal membership later.
Compliance-ready
PCI DSS Level 1 hosting, 3DS2, tokenisation, sanctions and PEP screening, transaction monitoring, audit trails aligned to PSD2 and PSD3.
Branded merchant & admin UI
White-label merchant portal, onboarding flows, KYB orchestration, risk console and reporting. No off-the-shelf logo in sight.
Weeks, not years
MVP processor stack live in 8-14 weeks. You focus on merchant acquisition and scheme certification while we ship the plumbing.
If you are serious about launching a payment processor in 2026, talk to the Crassula team. We will map your licence, sponsor and scheme path, and cost out the stack before you commit a single euro of build budget.
FAQ
The acquirer holds the merchant contract, carries the credit and chargeback risk, and is the regulated entity with Visa and Mastercard membership. The processor is the technical service that runs the switch: authorisation, clearing, settlement files and tokenisation. In practice many large players do both, but legally and commercially they are distinct roles with different licences.
Usually no. A pure processor (technical role) does not need a financial licence, only PCI DSS Level 1 and scheme certification. If you also want to hold merchant funds or issue cards, you need a Payment Institution or Electronic Money Institution authorisation in the EU, or the equivalent state or federal licences in the US. A full banking licence is only required if you take deposits or lend from your balance sheet.
PCI DSS Level 1 is the highest tier of the Payment Card Industry Data Security Standard, required for any entity that processes more than six million card transactions a year. It mandates annual audits by a Qualified Security Assessor, quarterly vulnerability scans, segmented network architecture, strong cryptography and tight change control. Under PCI DSS v4.0.1 (in force from April 2025) the controls are stricter around phishing resistance, authentication and targeted risk analysis. Any processor or PayFac of meaningful size needs it.
It depends entirely on the model. A gateway-only build can launch on €0.5-2M. A PayFac programme under a sponsor acquirer costs €1-3M including tech, compliance and launch capital. Full acquiring with a PI licence and Visa or Mastercard principal membership is €10-50M plus regulatory own funds. Ongoing scheme and compliance costs alone are six to seven figures per year once you are live.
Interchange is the fee the acquirer pays the issuing bank on every card transaction, set by the networks. In the EU it is capped at 0.2% for consumer debit and 0.3% for consumer credit under the Interchange Fee Regulation. In the US, Durbin-regulated debit is roughly 0.05% plus $0.22, while Durbin-exempt credit runs around 1.5%. Interchange is the single largest cost in the fee stack, and the main reason take rate looks thin when you model the economics properly.
A PSP (payment service provider) bundles a gateway, fraud tools and an acquirer relationship into a single commercial product; Stripe, Adyen and Checkout.com are classic examples. A PayFac (payment facilitator) goes one step further: it signs a single master agreement with a sponsor acquirer and then onboards sub-merchants under its own master MID with simplified KYB. PayFac is the default model for vertical SaaS and marketplaces that want payments inside their product.
A gateway-only product can go live in four to nine months. A PayFac programme under a sponsor acquirer usually takes six to twelve months. Full acquiring with a fresh PI or EMI licence and Visa or Mastercard principal membership runs 18 to 36 months, with a substantial chunk of that time spent on regulator and scheme review. Using a white-label core like Crassula cuts the tech build from roughly 12 months to 8-14 weeks.
There are three camps. Legacy cores like Fiserv, TSYS, Worldpay and Global Payments still power most banks and large acquirers. Modern platforms like Nuvei, Checkout.com, Adyen for Platforms and Marqeta offer cleaner APIs and faster PayFac onboarding. Most 2026 launches combine a white-label BaaS or processing core (Crassula, Solaris, Swan) with a modern acquirer and a specialist fraud engine, keeping each layer replaceable.
