/// Gateway · Whitelabel

Run a payment business under your own brand.

The same checkout that merchants integrate on our side, handed over as your product: your name on the payment page and the admin, your merchants onboarded under your rules, your pricing on every transaction, your team operating it. We build and run the software; the payment business is yours.

Yours
Brand, domain, admin
Multi
Merchant by design
SaaS
Or your own cloud
Card
+ stablecoin rails
/// Who runs it

Four ways this gets used.

The same platform, pointed at four different businesses. What changes is who your merchants are and where the margin comes from.

Payment providers

Launch or replace a gateway without building one. You own the merchant relationship, the pricing, and the brand; we own the software, the rails, and keeping it current.

Banks and acquirers

Give your merchant book a modern checkout without touching the core. Onboarding, pricing, settlement, and reporting sit in one console your team already understands.

Marketplaces and platforms

Embed payments into the product your sellers already use. Take payments on their behalf, split what's owed, and keep the whole flow inside your own interface.

Software vendors

Turn payments from a third-party redirect into a line of your own revenue. Your customers pay inside your product, and the economics stop leaving with them.

/// Your brand

Nothing on the screen says Protocore.

Whitelabel here means the whole surface, not a logo slot on a checkout. The payment page, the merchant back office, the operator console, the e-mails, the receipts, and the domains they all live on carry your identity. Your merchants sign up with you, log in to you, and get support from you.

  • [ 01 ]Payment page and admin on your own domains
  • [ 02 ]Logo, colors, typeface, and corner style across every surface
  • [ 03 ]Receipts, notifications, and onboarding e-mail sent as you
  • [ 04 ]Powered-by footer optional, and off by default
/// Your merchants

Onboard, tier, and manage a merchant book.

The platform is multi-merchant from the ground up rather than a single account with sub-accounts bolted on. Applications arrive, documents are collected, checks are recorded, and an approved merchant lands on the pricing tier you put them on — with everything about that decision on the record.

  • [ 01 ]Application, document collection, and review queue with an audit trail
  • [ 02 ]Pricing tiers and per-merchant overrides on fees and methods
  • [ 03 ]Method entitlements per merchant — cards, wallets, USDC, transfer
  • [ 04 ]Bulk import of an existing book, tokens and stored cards included
  • [ 05 ]Merchant-facing back office they use directly, branded as yours
/// Your economics

You set the pricing. The system does the arithmetic.

Fees are constructed rather than hard-coded: percentage, fixed, or both, by method, currency, card brand, region, and volume band, with different treatment for successful and failed attempts. Settlement then runs off the same definitions, so what a merchant is invoiced and what you are paid come from one calculation instead of two spreadsheets.

  • [ 01 ]Fee construction per merchant, method, currency, and volume band
  • [ 02 ]Rolling reserve, holds, and release schedules
  • [ 03 ]Automated settlement runs with a payout calendar
  • [ 04 ]Reconciliation across methods against one order reference
  • [ 05 ]Invoices and statements generated, sent, and tracked to paid
/// Your rails

Bring your acquirers. Keep your rates.

Your existing acquiring relationships stay yours — connected into the platform and routed by rules you write, so volume goes where your economics are best. Cards, wallets, bank transfer, local methods, and USDC run side by side on the same order model, and a new connection is a piece of configuration and an integration we build, not a project you staff.

  • [ 01 ]Your acquirers and providers connected alongside ours
  • [ 02 ]Routing by brand, issuer country, currency, amount, and merchant
  • [ 03 ]Cascading retry on soft declines, inside one checkout session
  • [ 04 ]Stablecoin acceptance with conversion, on the same rails as cards
  • [ 05 ]New connections built and certified as part of the service
/// Included

What comes with the platform.

  • Hosted checkout
  • Payment links
  • Mobile SDKs
  • Store plugins
  • Embedded fields
  • Card vault & network tokens
  • Subscriptions
  • 3-D Secure 2.0 / SCA
  • Fraud rules & lists
  • Dispute handling
  • Multi-currency pricing
  • USDC settlement
  • Merchant onboarding
  • Fee construction
  • Settlement & payouts
  • Reconciliation
  • Reporting & exports
  • Role-based access
  • Full audit trail
  • Signed webhooks
/// Your operators

The console your team actually works in.

Gateway's operator surface is Protocore Center: merchants, orders, payouts, disputes, and rails on one console, with roles scoped to the job. Support sees orders and issues refunds, finance sees settlement, risk sees flagged traffic, developers see keys and logs. Privileged actions require a reason and land in an immutable log, and any payment opens into a full trace.

  • [ 01 ]Roles and granular permissions instead of a shared login
  • [ 02 ]Reason-required privileged actions, written to an audit trail
  • [ 03 ]Order-level tracing from checkout to bank line
  • [ 04 ]Queues for onboarding, disputes, and flagged payments
  • [ 05 ]Every merchant's data visible to you, isolated from each other
/// Your infrastructure

Run it as a service, or run it yourself.

Take it as SaaS and we host, patch, monitor, and scale it. Or deploy it into your own cloud or data centre when your regulator, your bank, or your risk committee needs the system inside your own perimeter. The software is the same either way — what changes is who holds the keys and where the data sits.

  • [ 01 ]SaaS, your cloud, or on-premises
  • [ 02 ]EU processing and data residency by default
  • [ 03 ]Horizontal scale with monitoring and alerting included
  • [ 04 ]Regular releases, with new methods and rails arriving as updates
  • [ 05 ]Disaster recovery with replication across locations
/// Build vs. adopt

What it takes to have this next quarter.

Dimension
Building it yourself
Protocore whitelabel
Time to first live merchant
12–24 months before a real merchant processes, most of it spent on the parts nobody sees: vaulting, 3-D Secure, settlement, reconciliation.
Weeks. The platform exists; what takes time is your branding, your pricing, and your acquirer connections.
Team required
Payments engineers, a security function, an SRE rota, and someone who has certified a gateway before — hired before any of it earns.
Your commercial and operations people. The engineering that keeps a gateway current is ours.
PCI scope
Yours to design for, build to, and be assessed against — and to re-certify every year as the standard moves.
The card-handling surface is ours. Your scope is what you choose to touch, which is normally nothing.
Card vault
Encryption, key management, tokenization, and network token registration — the highest-risk component you would own.
Included, with network tokens and card updates handled behind your brand.
Method coverage
Each method is a separate integration, certification, and maintenance commitment, forever.
Cards, wallets, bank transfer, local methods, BNPL, and USDC ship together; new ones arrive as updates.
Stablecoin acceptance
A second stack — wallets, chains, pricing, conversion, custody policy — usually deferred and then never built.
On the same page and the same order as cards, converted and settled in fiat.
Keeping current
Scheme mandates, SCA changes, new methods, and security patches, on someone's roadmap permanently.
Part of the service. The platform moves whether or not you had capacity this quarter.
Merchant management
Onboarding, tiering, entitlements, and statements — a second product, built after the first one works.
Included, because a whitelabel platform is multi-merchant from the first line.
Cost shape
Heavy fixed cost up front and a permanent engineering line, whatever the volume does.
Cost tracks the business — licence and volume — with the build already amortised across the platform.
Where your effort goes
Into reaching parity with what already exists.
Into merchants, pricing, and distribution — the parts that are actually your business.
/// Commercials

How a whitelabel engagement is structured.

[ 01 ]

Platform licence

A licence scoped to the rails you enable, the merchant count you plan for, and the deployment you choose. Predictable, and independent of how well your book performs.

[ 02 ]

Volume-based

A per-transaction economic model with no platform fee to start — cost tracks the payments flowing through your merchants, so it scales with the business rather than ahead of it.

[ 03 ]

Build and operate

The platform plus the work around it: your acquirer integrations, your branding, migration of an existing book, and an operating relationship for the running of it.

What drives cost: the deployment (SaaS or your own infrastructure), the rails and methods you enable, the size of the merchant book, and whether we operate it with you. We'll model your numbers on a call rather than publish a figure that won't match your business.

/// The people

Not a support queue — the team that built it.

Protocore is a product studio. The people who answer when a settlement looks wrong are the people who wrote the settlement code, and the same team builds the acquirer connection you need, the report your regulator asked for, or the flow your market expects. That is the difference between a vendor and a partner, and it is the reason a whitelabel platform is worth adopting rather than licensing blindly.

  • [ 01 ]Direct access to the engineers who own the platform
  • [ 02 ]New connectors and methods built as part of the engagement
  • [ 03 ]Migration from an existing gateway planned and run with you
  • [ 04 ]Custom flows and reports built into your instance, not bolted on
/// Evaluate

What a first conversation gets you.

[ 01 ]

A walkthrough of the live platform

The merchant checkout, the merchant back office, and the operator console — the real screens, running, with a payment taken end to end.

[ 02 ]

Your brand on it

The checkout and admin rendered in your identity, so the thing you are evaluating looks like the thing you would ship.

[ 03 ]

A sandbox instance

A tenant of your own with API keys, test merchants, and webhooks, so your team can integrate against it before any commitment.

[ 04 ]

A migration and economics plan

How your existing merchants, tokens, and acquirer connections move across, and what the numbers look like against your volume.

/// FAQ

Questions payment providers ask.

  • You need whatever your market requires for the business you are in — we provide the software, not the regulated activity, and we are not in the flow of funds unless the model puts us there. Most partners run on their own acquiring or on an acquirer we introduce. We have supported partners through licensing conversations and can tell you plainly which parts of the stack the regulator will care about.

  • Yes — that is the normal case. Your relationships and your rates stay yours; the platform routes across them by rules you write. Connections we don't already have are built and certified as part of the engagement.

  • On SaaS, the card-handling surface is ours and your merchants inherit that — the page collecting card data is ours, wearing your brand. If you deploy on your own infrastructure, that surface moves inside your perimeter and is certified as part of your environment; we build to the standard and support the assessment.

  • Yes, and it's planned rather than improvised: merchant records and pricing come across in bulk, stored cards migrate as tokens so subscribers never re-enter details, and both platforms run in parallel while the old one finishes settling and refunding its own payments.

  • Completely, by design. Merchants see only their own orders, customers, payouts, and settings; your operators see across the book according to their role. Every privileged action is attributed and logged.

  • It arrives as a platform update. Scheme mandates, SCA rules, new methods, and security patches are our engineering problem, applied across the platform — which is most of the reason adopting one beats building one.

  • Yes. The same software deploys as SaaS, into your cloud account, or on-premises when a regulator or a risk committee requires the system inside your perimeter. Processing and data residency are EU by default in every case.

  • The same way they work for a merchant, one level up: the customer pays USDC, conversion happens before settlement, and what lands is fiat with the rate on the record. Your merchants take euros, and nobody in your chain ends up holding or custodying a token position.

  • Merchants, pricing, risk decisions, and support — the payment business. Uptime, releases, certifications, connector maintenance, and the parts of a gateway that never stop needing engineers are ours.

  • Weeks, not quarters. The platform exists; the sequencing is your branding, your pricing tiers, your acquirer connections, and a pilot merchant. Migration of an existing book runs alongside that rather than after it.

See it wearing your brand.

A walkthrough of the live platform, your identity on the checkout and the console, and an honest read on migration and economics against your volume.

Book a walkthrough