Start a Payment Company the Right Order

Most founders start with the tech and lose a year. Do it in the order that actually opens doors: settle your licence path, keep your card-data footprint small, line up acquirers, then decide what to build versus buy. Three gates are slow no matter what; the fourth is the only one you can compress from years to weeks.

Before choosing technology, be clear which role you are taking, because a gateway provider, an independent sales organisation (ISO), a payment facilitator (PayFac) and a regulated payment institution carry different responsibilities. A gateway provider supplies the technical layer that routes transactions. An ISO sells and onboards merchants for an acquirer or bank. A PayFac contracts with sub-merchants and takes on their underwriting and settlement under an acquirer's sponsorship. A regulated payment institution holds a licence to receive and move funds. Decide who contracts with merchants, who receives the funds and who is responsible for underwriting and settlement; that answer sets your licence path and how much of the stack you need to own.

“How do I start a payment processing company?” is really five questions:

• what licence you need
• how you meet PCI DSS and card-network requirements
• who actually moves money between banks
• what you build vs buy
• how you price so the economics work

Answer them out of order and you pay in lost time. This guide walks the gates in the sequence we use when we help a new processor go live.

Licence path

PI/EMI (EU/UK), MSB + state licences (US), or sponsor/PayFac. Sets independence vs speed.

→

Card-data footprint

Tokenize early, keep PAN off your servers, run on PCI DSS Level 1 rails. A design choice, not paperwork.

→

Acquirers & orchestration

More than one acquirer, smart routing and cascading to protect approvals. One acquirer is one point of failure.

→

Build vs buy

Own routing & brand — build the rails yourself or run on a white-label platform. Payneteasy: PCI DSS Level 1, 130+ fraud filters, 1,000+ integrations.

Your licensing path depends on whether you touch/hold funds, onboard merchants, act as PayFac, provide only technical processing, or operate as an acquirer/PSP.

Regulatory assessment, acquiring discussions and technical planning can progress in parallel once your operating model is clear. An existing platform can shorten technology implementation, but the overall launch still depends on approvals, contracts and testing.

In short: two gates you can't rush — the licence path and your acquirer set — and two you control — how much card data you touch, and whether you build the processing stack yourself or run it on white-label rails. The rest of this guide walks each gate in order, starting with the licence.

1. The first step to start a payment processing company: pick a licence path

Before committing to development, establish which activities your company will perform and which permissions they require. A technical gateway provider may not move or hold funds, while a regulated PSP or PayFac has different responsibilities.

Depending on the model, you may need your own authorisation, a registered agency or acquiring sponsorship arrangement, or a technical-services model that qualifies for an applicable exclusion. The two routes most new entrants compare first:

Get licensed yourself

In the UK and EU, regulated payment services may require payment institution authorisation or registration, or another permitted status. Issuing electronic money requires an appropriate e-money status. Certain technical services can qualify for an exclusion, but not holding funds alone does not establish that a business is outside regulation. In the US, MSB registration and state money-transmitter licensing depend on the activities and applicable exemptions; federal registration does not replace state licensing.

→

Operate under a sponsor's programme

Work through an acquiring sponsor or regulated principal under an agreed operating model. An ISO, an acquirer-sponsored PayFac and an agent of a regulated institution have different registration, underwriting and compliance responsibilities. Sponsorship does not automatically remove licensing requirements. A sub-merchant is the seller accepting payments through a PayFac, not the payment company itself.

This first fork is your earliest real decision:

Your own licence

Can provide greater control over the regulated service, but brings application, capital, governance and ongoing compliance obligations. It does not remove acquiring or technology costs.

vs

A sponsor / PayFac

May shorten the route to market, subject to partner approval, but introduces contractual limits and partner fees or revenue sharing.

Neither path is wrong. Starting the build before you've chosen one is.

2. Keep card data out of your own house

PCI DSS scope includes systems that store, process or transmit cardholder data, as well as systems that can affect the security of the cardholder data environment. Compliance effort depends on the architecture, integration model, segmentation and operational controls — not simply the amount of card data stored.

The strategic move is not "get certified at any cost." It's design your stack so you hold as little card data as possible, and keep your PCI scope — the slice of your systems auditors must inspect — as small as it can be.

Three design habits do most of the work:

Tokenise early

Tokenisation replaces the PAN with a substitute value and can reduce the number of systems handling card numbers. The scope reduction depends on the implementation and access to PANs or the token vault; tokens and the credentials used with them still require protection.

→

Avoid storing raw card data

Use appropriately implemented hosted fields or a hosted payment page to send card details directly to a PCI DSS-validated provider. Check the complete data flow and your remaining responsibilities: client-side encryption alone does not remove systems from PCI DSS scope.

→

Lean on a PCI DSS Level 1 platform

Certifying a large estate from scratch is typically a long multi-month project and a continuous obligation. Depending on the integration model, a PCI DSS Level 1 provider can reduce your own PCI scope.

Your card-data footprint is a design choice you make on day one, not a form you fill out at the end.

3. Line up your acquirers — and a route to more

A payment company is only as strong as the acquirers it can reach.

An acquirer is a financial institution authorised to acquire merchant card transactions through the relevant card schemes. A technical processor may handle transaction messages on its behalf, but is not necessarily the acquirer. Your card acceptance service needs an acquiring arrangement, with merchant funding governed by the agreed settlement model.

The failure mode almost nobody plans for is wiring yourself to a single acquirer:

With one acquirer, every such change is your problem. You have no routing choices.

So plan, from the start, for several acquirers — for geography, risk appetite, card profiles and redundancy — plus a routing layer that chooses between them.

That routing layer is payment orchestration: it coordinates connections, routing and transaction handling across providers. Routing selects an eligible connection using configured criteria such as geography, cost and observed performance. Cascading retries eligible failures where decline reasons, scheme rules and risk policy allow it. An unknown transaction outcome requires a status check before another attempt to avoid duplicate processing.

Ask which routing rules you can configure and which connections are available under your contracts. Multiple providers can improve resilience and create optimisation options, but they do not guarantee issuer approval or uninterrupted service.

4. Build or buy — where the timeline is won or lost

Building a gateway and processing stack from scratch is large:

Card-data handling

Tokenization and secure storage of cardholder data.

3-D Secure

And other authentication flows at checkout.

Routing & cascading

Logic that chooses and retries acquirers.

Fraud screening

And risk limits across your portfolio.

Reconciliation

And settlement reporting.

Payouts

Sending funds out on the same platform.

Per-acquirer integration

Provider-specific APIs, message formats, testing and certification requirements for each supported connection.

The development timeline depends on the scope, existing components and partner certification requirements. Budget for ongoing maintenance and security as well as the first production release.

The alternative is a white-label gateway: established payment technology that you operate under your own brand. Your control over configuration, data and migration depends on the platform and contract; branding does not imply ownership of the underlying infrastructure.

Payneteasy provides a PCI DSS Level 1 white-label gateway with smart routing, more than 130 configurable fraud filters and over 1,000 payment integrations. Its published launch timeframe of typically 1 week is a technology deployment estimate to confirm for your scope, not a promise that licensing, acquiring approval and merchant onboarding will be completed in that period. Payneteasy is a technology provider, not a bank, acquirer or PayFac, and does not hold merchant funds or provide merchant accounts.

5. Price for the spread, not the headline rate

The rate you quote a merchant is revenue, not profit. The spread remaining after acquiring and network costs must also cover technology, compliance, support and any losses you are contractually responsible for.

The core card acceptance cost components are:

Interchange

Paid to the card issuer (issuing bank), set by schemes, varies by card type, channel and region.

+

Scheme fees

Paid to networks (Visa, Mastercard, etc.).

+

Acquirer/processor margin

The acquiring or processing provider's charge above the underlying interchange and scheme costs.

Founders often fixate on the headline rate and ignore the stack below.

Two main pricing models:

Neither is automatically "better." It depends on who you sell to and how mature your merchants are.

Two practical steps before you publish a rate card:

Model your effective rate per merchant category

High-risk merchants, subscription SaaS, hospitality, and retail carry different fraud, chargeback and scheme-fee profiles. A single headline rate may work for one and fail for another.

→

Check fee tolerance in your target segments

In some verticals, merchants will accept a higher flat rate for simplicity; in others, they will demand interchange-plus transparency.

Build an initial cost model before committing to technology, then refine it with confirmed acquiring and platform quotes. Include setup costs, recurring minimums, compliance and support, plus capital or reserves where required. Pricing must work at realistic launch volumes, not only at the scale you hope to reach.