White-label payment infrastructure for acquiring banks
White-label payment gateway for low-risk PSPs
Built for high-risk PSPs — full control over your channels
A practitioner's guide to launching a payment service provider: choosing a model, signing an acquirer, licensing, PCI DSS, platform choice, cost drivers and a 9-step launch plan.
A white-label solution for PSPs is a ready-made processing platform that a payment service provider licenses and runs under its own brand, from the checkout to the back office. This guide is for you if you run a PSP and are deciding what to hand to a white label payment gateway provider, what to keep and how to grow.
It is the whole technology layer of a PSP business, rented instead of built: payment pages and application programming interfaces (APIs) for merchants, connectors to acquirers and payment methods, routing, risk rules, a merchant back office and reporting. You put your brand on it and sell it. The provider keeps the platform running, certified and up to date.
The features are those of any PSP software. What changes is the split of work: the provider ships and hosts the code, and you run the payment business on top of it. That business can take four shapes.
| PSP model | Holds merchant funds? | What the platform covers | What you add |
|---|---|---|---|
| Technical PSP | No. Acquirers settle to merchants directly | Checkout, routing, back office, reporting | Acquirer and merchant contracts, merchant KYC, PCI DSS for your own scope |
| Licensed payment or e-money institution | Yes, when you settle to merchants | The same, plus balances and settlement reports per merchant | Your authorisation, safeguarding of funds, an AML programme, outsourcing notices to your regulator |
| High-risk PSP (iGaming, Forex and similar) | Depends on the model | The same, plus card-history and traffic controls for routing | Several acquirers, stricter underwriting, reserve and chargeback policies |
| Aggregator or payment facilitator | Yes, for sub-merchants under a master account | Merchant hierarchy, fees and payouts per sub-merchant | Acquirer sponsorship, sub-merchant underwriting, liability for their chargebacks |
Your model decides your licence, not your software. A technical PSP that never comes into possession of the funds falls under the technical service provider exclusion in Article 3(j) of PSD2, the EU’s second Payment Services Directive. It still has to be registered with Visa as a service provider.
A payment institution that acquires payment transactions must hold initial capital of at least €125,000 under Article 7 of PSD2. If it settles to merchants, it must also safeguard their funds under Article 10. The licensing route is covered in our guide on how to start a payment processing company, and jurisdictions in our overview of payment service licences.
Go white label when time to revenue matters and your advantage lies in sales, risk or acquirer access rather than in gateway code. Build only with a long horizon, a funded engineering team and needs no platform meets. We estimate 12 months to 2 years to build a production-ready gateway in-house.
Compare the routes on cost over several years, not on launch fees: our three-year total cost of ownership calculator models both.
This guide covers running a PSP on white label, not choosing the vendor. Vendor selection has its own guide on how to choose a white-label payment platform.
The provider runs the software, the connectors, the hosting on SaaS and the platform’s PCI DSS certification. You keep everything that regulators, acquirers and merchants hold you to: the licence, acquirer contracts, merchant due diligence, the fraud and chargeback exposure your acquirer contract puts on you, pricing and first-line support.
| Area | You (the PSP) | The provider (eComCharge) |
|---|---|---|
| Licence and regulator | Hold the licence or work under a licensed partner; notify the regulator of outsourcing | Not a party: you remain the regulated entity |
| Acquiring | Sign acquirer agreements; agree merchant IDs (MIDs), descriptors and reserves | Builds and maintains connectors; develops new ones on request |
| Merchant onboarding | Run KYC, assess risk, approve or decline each merchant | Merchant hierarchy with roles, shops, permissions and limits |
| Fraud and chargebacks | Set rules and limits, answer disputes; cover merchant losses where your acquirer contract or sub-merchant model makes you liable | Routing and anti-fraud rules, 3-D Secure, blacklists, chargeback records |
| PCI DSS | Your own systems, staff access and merchant integrations | The certified platform; on SaaS, hosting under its Level 1 certification |
| Infrastructure | On your own servers only: hardware, firewalls and network to PCI DSS | All of it on SaaS; installation and support on your servers |
| Support | First-line support for merchants | 24/7 technical support for you; merchant support on your behalf as a paid option |
| Pricing | Merchant fees, foreign exchange (FX) margins and surcharges | Fixed, percentage or hybrid commission models to configure |
Under Article 19(6) of PSD2, a payment institution that outsources operational functions informs its home regulator. Outsourcing important functions, IT systems included, must not weaken internal control or supervision. Article 20 keeps the institution fully liable for any entity it outsources to.
Card schemes take the same line. Visa requires its issuers, acquirers and merchants to use PCI DSS compliant service providers. A Level 1 provider validates every 12 months with an Attestation of Compliance (AOC) from a Qualified Security Assessor (QSA), under Visa’s service provider rules.
Ask for the provider’s current AOC before your acquirer does. If you weigh your own audit against a vendor’s, read our post on outsourcing PCI DSS.
Underwriting stays with you: if you serve risky verticals, see our guide to high-risk onboarding.
You need a commercial and risk organisation, not a gateway engineering team. Six functions cover the work: sales, onboarding and compliance, risk and chargebacks, payment operations, merchant support and finance. In a small PSP a few people share the roles, but none of the functions goes away.
Wins merchants and resellers, sets merchant pricing in the fixed, percentage or hybrid commission models the platform supports, and negotiates with acquirers.
Runs KYC and AML checks, owns the AML programme and keeps the records your regulator and acquirers audit.
Sets transaction limits, blacklists and reserves, tracks fraud and chargebacks per merchant and answers disputes.
Configures routing and connectors, watches approval rates by acquirer, manages MIDs and talks to the provider’s support.
Answers integration and payment questions under your brand. eComCharge can take this on for an additional fee; 25% of its clients use that service.
Reconciles acquirer settlements with merchant balances using the platform’s financial statements and invoices your fees.
Your technical headcount is small: no developers for connectors, 3-D Secure or certification and, on SaaS, no infrastructure team.
Two technical skills still pay off: a solutions engineer who knows the API shortens merchant integrations, and back-office know-how keeps daily work moving. Most daily work happens in the back office, so plan training around merchant management and routing rules.
Launch runs on two tracks. You own the commercial track: licence path, acquirers and first merchants. The provider owns most of the technical track: installation, branding, connectors and tests. On eComCharge the technical track takes from 1 week on SaaS and from 3 months on your own servers.
Decide whether merchant funds will pass through your accounts. That answer decides whether you need your own licence or a licensed partner.
Sign at least one acquirer and agree which merchant categories it will accept. Expect it to ask for the platform provider’s PCI DSS AOC.
Pick SaaS, your own servers or a lifetime licence (a one-off purchase you run on your servers with full control). Write data export, token migration and exit terms into this contract, not a later one.
eComCharge installs and brands the payment pages, widget and back office. You set fees, limits, currencies and routing rules. Our post on white label setup time explains what drives this step.
eComCharge enables the acquirer connector, or develops a new one on request. You and the acquirer test payments, 3-D Secure, refunds and chargebacks.
If you are licensed, inform your regulator of the outsourcing. Write down the split of responsibilities with the provider and the acquirer.
Verify each merchant, then let it integrate without coding through plugins, payment links or the hosted page. Start with low-risk merchants and tight limits.
Scale in a fixed order: acquirers first for resilience and approval rates, then payment methods and markets, then new merchant segments, and the infrastructure model last. At each stage you mostly sign contracts and change configuration; the provider adds connectors, features or capacity.
| Stage | Trigger | What you add | Who does what |
|---|---|---|---|
| 1. More acquirers | One acquirer carries all volume | A backup acquirer, routing and cascading rules | You sign; eComCharge connects it from its 170+ connectors or develops a new one on request; you write the rules |
| 2. Methods and markets | Merchants sell abroad or ask for local methods | Local acquiring, wallets, Open Banking, currencies | You sign the providers; eComCharge builds missing connectors |
| 3. Merchant segments | Subscriptions, platforms or high-risk verticals | Tokens and retries, sub-merchant hierarchy, card-history checks | You underwrite; eComCharge supplies the features |
| 4. Infrastructure | One merchant slows others, or data must stay on your servers | Dedicated servers inside SaaS, or your own servers | eComCharge allocates or installs; on-premises you run the servers |
A single acquirer is a single point of failure: if it ends the relationship or slows down, every merchant stops. A multi-acquirer strategy pairs a second acquirer with routing rules and cascading, which retries an eligible decline on another route.
Each new market needs a local acquirer or method provider, which you contract. eComCharge has 170+ active connectors with banks and payment methods and completes at least 6 new connector integrations a month for its clients. Ask for the connector list for your target country before you sign the provider there.
Each segment needs one capability before you sell to it. Subscription merchants need tokenization and smart retries. High-risk merchants need card history in routing: SmartCheck tracks 16 metrics per card over 360 days. A high-risk iGaming PSP used it to grow volume 3× in 12 months without new MIDs.
An eComCharge installation on your own servers takes from 3 months, so treat the move as a response to a real trigger, such as data residency rules. When one large merchant slows a shared environment, eComCharge can assign dedicated servers inside SaaS instead. The trade-offs of an on-premises payment gateway are in our separate post.
Your margin on a transaction is your merchant fee minus the platform’s fees and, when you settle to merchants, minus interchange, scheme fees and the acquirer’s markup. Your strongest lever is the share of attempts that end as approved, low-risk payments: each approval earns the margin and each fraud case costs it.
| Driver | How it moves your margin | Lever on the platform |
|---|---|---|
| Approval rate | A declined attempt earns nothing but can still cost fees | Routing, cascading and 3-D Secure rules |
| Acquirer cost mix | Where you pay acquirer costs, they differ by card type, region and acquirer | bank identification number (BIN) routing to the cheaper eligible route |
| Fraud and chargebacks | Losses, dispute fees and acquirer penalties | Limits, blacklists, card-history checks |
| Fixed platform fees | Weigh heavily at low volume and fade as volume grows | Start on SaaS; revisit the model as volume grows |
| Cost per merchant | Onboarding and support grow with merchant count | Plugins, payment links, outsourced merchant support |
| FX and surcharges | Extra margin on currency conversion and pass-through fees | Custom FX rates and surcharges |
Assumptions, made up for the example: 100,000 payment attempts a month, a margin of m on each approved payment, a fixed monthly platform fee F, and an approval rate that rises from 85% to 88% after you add a second acquirer and cascading.
eComCharge pricing depends on your specific needs, such as the deployment model, volume, connectors and customisation, so contact our sales team for a quote. Revenue streams and pricing models for your merchants are covered in our guide to the payment gateway business model.
Migrate in waves, not in one cut-over. Take stock of what you run, connect your acquirers to the new platform, move stored card tokens, then switch merchants in groups while the old gateway still runs. Stored tokens and merchant integrations decide whether shoppers notice the move.
List merchants and their integration types, acquirer accounts, stored tokens and who holds them, recurring schedules and open disputes.
Confirm with each acquirer that existing merchant accounts can be connected to the new platform. eComCharge configures the connectors.
The outgoing party exports card data securely and the new platform issues new tokens. In one token migration, a high-risk PSP moved 95% of the available tokens in about one week.
Start with merchants on the hosted page, who change credentials and endpoints, and plugin merchants, who install your new plugin and enter new credentials. Move API merchants next. Keep the old gateway live for refunds and chargebacks on earlier payments.
Reconcile both platforms until disputes on old transactions close, archive the data, then switch the legacy gateway off.
A token migration needs three things: an outgoing provider willing to share the tokenised data, a receiving acquirer that accepts migrated tokens, and compatible formats. Agree on the first in your current contract before you announce the switch.
If you are a bank moving a whole acquiring stack, our legacy migration guide covers the larger version of this project.
Most risks are concentration risks: on one acquirer, one provider, one large merchant or one shared environment. Each has a fix you can set up before it hurts. The last one, leaving the provider, belongs in the contract you sign on day one.
| Risk | What it looks like | How to reduce it |
|---|---|---|
| Acquirer concentration | A shut-off or slowdown at one acquirer stops all merchants | A second acquirer and fallback rules. In one acquirer failure, eComCharge support isolated a slowing acquirer in seconds |
| Provider dependence | An outage or a slow roadmap at the provider reaches your merchants | A service level agreement (SLA) on uptime and response times, 24/7 support, your own monitoring |
| Shared resources | One merchant’s load slows the rest | Dedicated servers for that merchant, or a dedicated PSP environment |
| Merchant risk | A fraud or chargeback spike at one merchant puts your acquirer accounts at risk | Limits, reserves and per-merchant monitoring from day one |
| Fixed-fee drag | Platform fees outpace early volume | Model break-even volume first; start on SaaS |
| Lock-in | Tokens, data and merchants live on one platform | Export formats, token migration terms and an exit clause in the contract |
The EU’s Digital Operational Resilience Act (DORA) has applied to payment and e-money institutions since 17 January 2025. Article 28 of DORA keeps you fully responsible for compliance when you use information and communication technology (ICT) providers. For ICT services that support critical or important functions, it requires documented exit strategies.
The test of an exit plan is the wording in Article 28(8): you must be able to leave without disrupting your business, limiting compliance or harming service to clients. In practice that means a named export format for merchant and transaction data, a token migration path and a notice period long enough to run the migration steps above.
eComCharge develops the white-label platform on which 125+ PSPs and financial institutions have launched and scaled payment services under their own brand. You run it on SaaS, with installation from 1 week, or on your own servers or under a lifetime licence, with installation from 3 months.
See how the platform is set up for low-risk PSPs and for iGaming and Forex PSPs, or read about our white-label payment gateway.
It is a ready-made payment processing platform that a payment service provider licenses from a vendor and sells under its own brand. It covers payment pages, APIs, connectors to acquirers and payment methods, routing, risk rules, a merchant back office and reporting. The vendor maintains and certifies the software; you run the payment business on it.
It depends on whether merchant funds pass through your accounts. In the EU, a technical PSP that never holds funds falls outside PSD2 under the Article 3(j) exclusion and works on acquirer contracts and scheme registration. If you settle funds to merchants, you need your own authorisation or a licensed partner; an EU payment institution that acquires payment transactions needs initial capital of at least €125,000.
Not the platform provider. The acquirer debits chargebacks to the merchant; you are liable towards your acquirer where your contract says so, and for all sub-merchants if you work as an aggregator or payment facilitator. The platform supplies the tools, such as routing and anti-fraud rules, 3-D Secure, limits and chargeback records; you set the rules and underwrite the merchants.
On eComCharge, a SaaS installation takes from 1 week and an installation on your own servers from 3 months. The commercial track usually takes longer: acquirer agreements, your licence or licensed partner, and verifying your first merchants. Plan the go-live date around the acquirer, not the software.
Usually, if you plan for it. Your acquirers connect to the new platform through connectors, and stored card tokens can be migrated when the outgoing provider shares the data in a compatible format. In one eComCharge case, a high-risk PSP moved 95% of the available tokens in about one week.
There is no list price. eComCharge pricing depends on your specific needs, such as the deployment model, transaction volume, connectors and customisation, so contact our sales team for a quote. Budget also for your own licence, compliance, risk and support staff.
Yes, as an option for an additional fee. The eComCharge team then talks directly to your merchants and acquiring banks on your behalf, so you do not need to hire dedicated technical support staff. A quarter of eComCharge clients use this service; technical support for you as the PSP is 24/7 by default.
Start on SaaS unless a rule or policy keeps data on your own servers. SaaS is the fastest to launch and leaves hosting and the platform's PCI DSS scope with eComCharge. On your own servers you run the hardware, firewalls and network yourself. A high-volume merchant can also get dedicated servers inside SaaS.
eComCharge develops and delivers the PCI DSS Level 1 certified white-label payment platform for Payment Service Providers and Payment Orchestration.
A practitioner's guide to launching a payment service provider: choosing a model, signing an acquirer, licensing, PCI DSS, platform choice, cost drivers and a 9-step launch plan.
How PSPs, acquiring banks and EMIs onboard high-risk merchants: which MCCs count as high risk, the KYB, UBO and sanctions checks EU law requires, underwriting and reserves, Visa registration and monitoring, what to automate and how to keep an evidence trail.
How a PSP protects itself from a sudden acquirer shut-off, outage or limit change: concentration risk, scheme and underwriting triggers, backup acquirers, portable tokens, volume split, an outage runbook, costs and who does not need it.
A guide to cascading payments for PSPs and acquiring banks: soft, hard and technical declines, which Visa response codes may cascade, cascade design, duplicate-charge prevention, 3DS, scheme rules, recovery KPIs and who should not cascade.
A guide for PSPs, banks and platforms on custom payment solutions: custom build vs off-the-shelf vs white-label, what can be customised, how a connector or payout flow is scoped and delivered, what drives cost and time, and the risks.
The four types of payment tokenization service provider for PSPs and banks, network vs gateway tokens, token portability and migration, PCI DSS scope, and the questions to ask before you choose.