---
title: "White-Label Solution for PSPs: Run and Scale"
description: "A white-label solution for PSPs: what the provider runs and what you keep, the team you need, launch steps, growth stages, migration and exit planning."
url: "https://ecomcharge.com/guides/white-label-solution-for-psp/"
lang: "en"
date_published: "2025-03-28"
last_updated: "2026-11-10"
author: "Oksana Mikhailovskaya"
image: "https://ecomcharge.com/static/assets/img/guides/white-label-solution-for-psp/white_label_psp.31bb749a319b.png"
breadcrumbs: "Home > Guides > White-Label Solution for PSPs: How to Run and Scale Your Payment Business"
---

[Guides](https://ecomcharge.com/guides/)

White Label

# White-Label Solution for PSPs: How to Run and Scale Your Payment Business

![Oksana Mikhailovskaya](https://ecomcharge.com/static/assets/img/authors/oksana-mikhailovskaya.ba234e7ec63f.jpg)

[Oksana Mikhailovskaya](https://www.linkedin.com/in/oksana-mikhailovskaya-2b661725/)

March 28, 2025

14 min read

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](https://ecomcharge.com/guides/white-label-payment-gateway/) provider, what to keep and how to grow.

### Key takeaways

1. When it fits: your edge is merchants, risk skills or acquirer access, not gateway code.
2. What you keep: the licence or licensed partner, acquirer contracts, merchant KYC, fraud and chargeback exposure towards your acquirer, pricing and first-line support. Outsourcing the platform moves work, not liability.
3. Launch: an eComCharge software-as-a-service (SaaS) installation takes from 1 week and an installation on your own servers from 3 months. Acquirer contracts usually set the real go-live date.
4. Growth order: acquirers first, then payment methods and markets, then merchant segments. Change the infrastructure model last.
5. Exit: agree it at signing. EU payment and e-money institutions need exit strategies for critical information and communication technology (ICT) services under DORA, the Digital Operational Resilience Act.

## What Is a White-Label Solution for a PSP?

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](https://ecomcharge.com/guides/payment-service-provider-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 models a white-label solution can serve

| 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](https://eur-lex.europa.eu/eli/dir/2015/2366/oj), the EU’s second Payment Services Directive. It still has to be [registered with Visa](https://usa.visa.com/content/dam/VCOM/regional/ap/documents/data-security-compliance-service-providers.pdf) 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](https://eur-lex.europa.eu/eli/dir/2015/2366/oj). 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](https://ecomcharge.com/guides/how-to-start-a-payment-processing-company/), and jurisdictions in our overview of [payment service licences](https://ecomcharge.com/blog/payment-service-licenses/).

## When Should a PSP Go White Label Instead of Building?

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.

#### White label fits

- You are launching a PSP and want first transactions in months: an eComCharge SaaS installation takes from 1 week.
- Your in-house gateway spends most engineering time on connectors, certification and upkeep.
- You plan to add acquirers, methods or markets faster than your team can build connectors.
- You want a platform certified at PCI DSS Level 1, the top validation level for service providers, without certifying the whole stack yourself.

#### Look at other options

- You accept payments only for your own sales: a standard gateway account is simpler.
- You want referral income without onboarding, risk or support duties: a referral agreement fits.
- Your processing logic is the product: build it, or license the source code.
- You have no acquirer access or licence path yet: solve that first, software will not.

Compare the routes on cost over several years, not on launch fees: our [three-year total cost of ownership](https://ecomcharge.com/blog/build-vs-buy-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](https://ecomcharge.com/guides/white-label-payment-platform/).

## What Does the Provider Run, and What Stays With the PSP?

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.

Who does what when a PSP runs on eComCharge

| 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 |

Rule

### PSD2 on outsourcing

Under [Article 19(6) of PSD2](https://eur-lex.europa.eu/eli/dir/2015/2366/oj), 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](https://usa.visa.com/content/dam/VCOM/regional/ap/documents/data-security-compliance-service-providers.pdf).

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](https://ecomcharge.com/blog/outsourcing-pci-dss-in-modern-banks/).

Underwriting stays with you: if you serve risky verticals, see our guide to [high-risk onboarding](https://ecomcharge.com/guides/automate-high-risk-onboarding/).

## What Team Does a PSP Need on a White-Label Platform?

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.

#### Sales and partnerships

Wins merchants and resellers, sets merchant pricing in the fixed, percentage or hybrid commission models the platform supports, and negotiates with acquirers.

#### Onboarding and compliance

Runs KYC and AML checks, owns the AML programme and keeps the records your regulator and acquirers audit.

#### Risk and chargebacks

Sets [transaction limits](https://ecomcharge.com/blog/setting-transaction-limits/), blacklists and reserves, tracks fraud and chargebacks per merchant and answers disputes.

#### Payment operations

Configures routing and connectors, watches approval rates by acquirer, manages MIDs and talks to the provider’s support.

#### Merchant 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.

#### Finance

Reconciles acquirer settlements with merchant balances using the platform’s [financial statements](https://ecomcharge.com/blog/begateway-financials/) 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](https://ecomcharge.com/guides/white-label-merchant-management/) and routing rules.

## How Do You Start a White-Label PSP, Step by Step?

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.

1. #### Fix the model and licence path (you)

   Decide whether merchant funds will pass through your accounts. That answer decides whether you need your own licence or a licensed partner.
2. #### Sign acquirers (you and the acquirer)

   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.
3. #### Choose deployment and sign (you and eComCharge)

   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.
4. #### Install, brand and configure (eComCharge, then you)

   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](https://ecomcharge.com/blog/time-for-deploying-white-label-payments/) explains what drives this step.
5. #### Connect and test (eComCharge and the acquirer)

   eComCharge enables the acquirer connector, or develops a new one on request. You and the acquirer test payments, 3-D Secure, refunds and chargebacks.
6. #### Notify and document (you)

   If you are licensed, inform your regulator of the outsourcing. Write down the split of responsibilities with the provider and the acquirer.
7. #### Board the first merchants (you)

   Verify each merchant, then let it [integrate without coding](https://ecomcharge.com/blog/integrate-merchants-gateway/) through plugins, payment links or the hosted page. Start with low-risk merchants and tight limits.

eComCharge white-label platform

### Scale Your PSP Under Your Own Brand

Launch on the eComCharge white-label platform and add acquirers and payment methods as you grow.

- PCI DSS Level 1 since 2012
- 170+ connectors
- SaaS launch from 1 week

[Request demo](https://ecomcharge.com/contacts/sales/)

## How Do You Scale a PSP on a White-Label Solution?

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.

Growth stages for a PSP on a white-label platform

| 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 |

### Stage 1: add acquirers before you need them

A single acquirer is a single point of failure: if it ends the relationship or slows down, every merchant stops. A [multi-acquirer strategy](https://ecomcharge.com/guides/multi-acquirer-protection-strategy/) pairs a second acquirer with routing rules and [cascading](https://ecomcharge.com/guides/recover-declined-transactions-cascading/), which retries an eligible decline on another route.

### Stage 2: add payment methods and markets

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.

### Stage 3: add merchant segments

Each segment needs one capability before you sell to it. Subscription merchants need [tokenization](https://ecomcharge.com/platform/tokenization/) and smart retries. High-risk merchants need card history in routing: [SmartCheck](https://ecomcharge.com/platform/smartcheck/) tracks 16 metrics per card over 360 days. A high-risk iGaming PSP used it to [grow volume 3× in 12 months](https://ecomcharge.com/case-studies/3x-volume-growth/) without new MIDs.

### Stage 4: change the infrastructure model last

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](https://ecomcharge.com/case-studies/dedicated-infrastructure/) inside SaaS instead. The trade-offs of an [on-premises payment gateway](https://ecomcharge.com/blog/premises-payment-gateway-for-psp/) are in our separate post.

## What Drives the Unit Economics of a White-Label PSP?

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.

Margin drivers and the platform lever for each

| 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](https://ecomcharge.com/blog/bin-routing-cost-reduction-payment/) 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 |

Illustrative example

### What three points of approval rate are worth

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.

1. Approved payments rise from 85,000 to 88,000: 3,000 more a month.
2. Margin rises by 3,000 × m a month, with the same merchants.
3. The fixed fee per approved payment falls only slightly, from F / 85,000 to F / 88,000.
4. At ten times the volume, it falls to F / 880,000. Volume, not approval rate, dilutes fixed fees.

eComCharge pricing depends on your specific needs, such as the deployment model, volume, connectors and customisation, so [contact our sales team](https://ecomcharge.com/contacts/sales/) for a quote. Revenue streams and pricing models for your merchants are covered in our guide to the [payment gateway business model](https://ecomcharge.com/guides/payment-gateway-business-model/).

## How Do You Migrate From a Legacy Gateway to a White-Label Solution?

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.

1. #### Take inventory (you)

   List merchants and their integration types, acquirer accounts, stored tokens and who holds them, recurring schedules and open disputes.
2. #### Connect acquirers (you, the acquirer and eComCharge)

   Confirm with each acquirer that existing merchant accounts can be connected to the new platform. eComCharge configures the connectors.
3. #### Move tokens (the outgoing provider and eComCharge)

   The outgoing party exports card data securely and the new platform issues new tokens. In one [token migration](https://ecomcharge.com/case-studies/token-migration-one-week/), a high-risk PSP moved 95% of the available tokens in about one week.
4. #### Switch merchants in waves (you and your merchants)

   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.
5. #### Reconcile and retire (your finance team)

   Reconcile both platforms until disputes on old transactions close, archive the data, then switch the legacy gateway off.

Important

### Tokens move only if the old side cooperates

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](https://ecomcharge.com/blog/legacy-migration-guide-moving-your-banks/) covers the larger version of this project.

## What Are the Risks for a PSP, and How Do You Plan the Exit?

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.

PSP risks on a white-label platform and how to reduce them

| 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](https://ecomcharge.com/case-studies/acquirer-failure-contained/), 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 |

Rule

### DORA exit strategies

The EU’s Digital Operational Resilience Act (DORA) has applied to payment and e-money institutions since 17 January 2025. [Article 28 of DORA](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) 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.

## How eComCharge Supports PSPs

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.

### What a PSP gets

- PCI DSS Level 1 compliance, with annual security audits since 2012.
- 170+ active connectors with banks and payment methods, and new connectors on request.
- [Smart Routing](https://ecomcharge.com/platform/smart-routing/) with 50+ routing conditions, SmartCheck card history and a [3DS Server](https://ecomcharge.com/platform/3ds-server/) certified by Visa, Mastercard and UnionPay.
- Payment pages in 25+ languages, mobile software development kits (SDKs), 40+ shopping cart plugins and payment links.
- 24/7 technical support, a dedicated data warehouse for each PSP and optional support for your merchants.

See how the platform is set up for [low-risk PSPs](https://ecomcharge.com/solutions/psp/) and for [iGaming and Forex PSPs](https://ecomcharge.com/solutions/igaming-and-forex/), or read about our [white-label payment gateway](https://ecomcharge.com/white-label-payment-gateway/).

## Frequently asked questions

### What is a white-label solution for a PSP?

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.

### Do I need a licence to run a PSP on a white-label solution?

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](https://eur-lex.europa.eu/eli/dir/2015/2366/oj) 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.

### Who is liable for fraud and chargebacks on a white-label platform?

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.

### How long does it take to launch a PSP on a white-label solution?

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.

### Can I keep my acquirers and stored cards when I switch to a white-label solution?

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.

### How much does a white-label solution for a PSP cost?

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](https://ecomcharge.com/contacts/sales/) for a quote. Budget also for your own licence, compliance, risk and support staff.

### Can eComCharge support my merchants for me?

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.

### Should a PSP choose SaaS or its own servers?

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.

---

### Respectfully, the eComCharge Team

eComCharge develops and delivers the PCI DSS Level 1 certified white-label payment platform for Payment Service Providers and Payment Orchestration.

[Request demo](https://ecomcharge.com/contacts/sales/)

## Set up your payment processing system

in 7 days, not a year

[Request demo](https://ecomcharge.com/contacts/sales/)