How to launch a white-label payment service

A white-label payment service is not only a branded interface. It requires a clear legal model, provider relationships, technical lifecycle and daily operating capability.

Define the role before the product surface

Decide whether the business is acting as a merchant service layer, technical platform, PSP, agent or another regulated participant. Confirm licensing, contracting, onboarding, data and settlement responsibility with qualified advisers before presenting capabilities to merchants.

Build provider coverage around target jobs

Start with markets, verticals, methods, currencies and merchant requirements. Distinguish a provider catalogue from routes that can actually onboard the intended merchants. Record commercial terms, payment experience and readiness state.

Connect the complete lifecycle

Document deposits, payouts, refunds, statuses, callbacks, tokenization and other required operations. Keep one merchant-facing contract where appropriate while preserving original provider responses for support and audit.

The brand can be white-labelled; responsibility, evidence and provider constraints cannot be made invisible.

Design operations before launch

Plan routing ownership, monitoring, first-line support, provider escalation, reconciliation, expected settlement and audit history. Define which team owns each action and what the merchant sees. Test a real incident and provider report before onboarding live traffic.

Where PayStar fits in a white-label operating model

Choose the capability your team needs to add. Discovery, Direct Connect and Core address different jobs and can be used separately; the scope starts with your operating model and the PSP capabilities confirmed for it.

Qualify suitable routes with Discovery

If the provider choice is still open, PayStar Discovery helps turn market and payment requirements into a PSP shortlist. Bring the merchant entity, target countries, vertical, licences, currencies, payment methods and expected volumes. The result is a clearer view of provider fit, commercial context and requirements to investigate. A shortlisted PSP still needs to approve the merchant; the merchant chooses and contracts with the provider.

Connect selected PSP capabilities with Direct Connect

If the PSPs are selected, PayStar Direct Connect provides a stable merchant-facing API with provider adapters behind it. Bring the required operations, provider documentation and confirmed integration scope. Each pipeline uses its own key, while normalized results retain the original PSP context. The merchant's direct PSP relationships remain in place; the PSP processes payments and fulfils its settlement obligations under that agreement.

Operate connected routes with Core

If the routes are connected, PayStar Core supports routing, monitoring, investigation, controlled resolution and reconciliation. Bring the current PSP set, merchant-approved routing policy, support ownership and a representative PSP report. The operating record connects policy context, attempts, callbacks and provider evidence so the team can investigate outcomes and assign the next action.

Choose how a missing adapter is developed

If a required adapter is not already available, agree who will develop it and what the development order should cover.

With Standard Integration, PayStar develops an adapter for the agreed operations. Standard development costs €750, with an estimate of around 10 business days; the plan depends on confirmed scope, documentation, access and PSP responses. PSP fees, PayStar product subscriptions and additional work are not automatically included in that price.

With Fast-track Integration, PayStar handles a separately accepted accelerated development order with an agreed scope, fixed development price and delivery window.

With Self-integration, a dedicated developer implements, tests and maintains your APM adapter on PayStar infrastructure. We can help you find and prepare the specialist. Self-integration covers alternative payment methods only; card payment adapters are developed exclusively by PayStar.

These are separate ways to organise adapter development, selected according to the work your team needs.

Ask for evidence before choosing a branded service

A product name or a branded interface does not define the full delivery scope. Use these questions in the architecture review:

• Which requested operations and payment methods are confirmed for each PSP and merchant context?
• Who owns onboarding, the PSP agreement, routing policy, support escalation and settlement responsibility?
• What can be demonstrated for branding controls, separation between merchant accounts and access permissions? Record anything that still needs confirmation.
• Can the team trace one failed payment and explain one report difference using the original provider evidence?
• Which commercial arrangements, including any reseller model, are actually agreed for this service?

Attach the source and owner to each answer. Use the platform evaluation guide to turn the discussion into a review of specific payment jobs and evidence.