A white-label crypto payment gateway should be evaluated as an operating arrangement, not merely a checkout with your logo. Distinguish a hosted interface, an API-led payment integration and a contracted branded service. Then verify who onboards customers, controls funds, settles payments, handles refunds and owns support.
Which operating model are you actually buying?
For this guide, hosted/branded checkout means a provider-hosted payment interface with agreed presentation controls. API-led integration means your application implements parts of the journey around provider endpoints. White-label operating arrangement means the provider explicitly offers a service under the buyer's brand, with its actual responsibilities defined in the agreement.
These are working procurement definitions, not universal vendor terminology. A product may combine models. The useful question is what your company can control and what it must delegate.
| Model | Branding question | Workflow question | Evidence before launch |
|---|---|---|---|
| Hosted/branded checkout | Which screens, URLs and disclosures can change? | When does the customer enter or leave the provider interface? | Annotated checkout and written customization scope |
| API-led integration | Which screens does our team build? | Which actions, callbacks and lookups must we implement? | API contract, failure cases and responsibility map |
| White-label arrangement | What can legally and operationally use our brand? | Who operates onboarding, money movement and support? | Explicit offering plus executed agreement and operating schedule |
The table is FluidRWA's buyer framework, not a scored vendor comparison. More interface control can mean more implementation responsibility; it does not establish control over funds or regulatory responsibility.
What do current named examples establish?
B2BINPAY: an explicitly marketed white-label offering
B2BINPAY's white-label solution page explicitly markets a white-label crypto payment gateway, describing interface customization, wallet functionality, conversions and API integration. This is the company's stated offering, not independent verification of delivery or suitability.
Verification Required: the contracting entity, custody arrangement, enabled settlement options, support obligations and the actual branding scope available to your company. A marketing page is not a substitute for those documents.
Cryptomus: an API integration example, not white-label proof
Cryptomus's merchant payment webhook documentation describes payment-status callbacks and payload fields including order identifiers and payment amounts. That supports discussion of an API-led merchant integration. This source does not establish an explicit white-label offering, so we do not classify it as one.
Ask for an invoice-to-ledger demonstration rather than treating a webhook screenshot as proof of settlement completeness.
Transak: a white-label ramp, not evidence of a merchant gateway
Transak's Whitelabel API documentation describes a fiat funding journey with product-specific limitations and provider-controlled verification/payment steps. Its limitations table lists OffRamp as unsupported for that API scope. Do not extend that statement to all Transak products, or interpret a white-label ramp as a white-label merchant gateway.
Use the existing MoonPay, Transak and Banxa onboarding dataset for sourced ramp details. This guide does not reproduce that vendor comparison.
Who owns onboarding and customer disclosures?
The following sections are procurement recommendations, not claims about the named providers.
Request a responsibility map covering merchant onboarding, customer identification where applicable, verification decisions, screening, data collection, retention and escalation. Identify every party the customer must agree to contract with.
Have the provider mark the screens where your brand may appear and where its entity, terms or privacy notice must remain visible. Ask who can approve changes and whether a review is required before each release. A polished demo does not resolve these contractual questions.
How should settlement and refunds be specified?
Start with a complete money-flow diagram: payer, receiving address or account, conversion step, balance holder, merchant and destination. Ask which party can hold, convert, withdraw or freeze funds. Do not infer custody from the words API, gateway or white-label.
Specify the asset, network, payout destination, timing basis, minimums, fees and exceptions in the contract. Obtain sample statements showing how invoices map to receipts, conversions and payouts. Keep invoice payment confirmation separate from evidence that the merchant received spendable funds.
For refunds, request a worked example with recipient checks, approval authority, currency/network choice, exchange-rate treatment, charges and the original-payment reference. Include partial refunds, overpayments and underpayments in the demonstration. Do not promise reversibility or automatic recovery unless the provider documents it for your configuration.
What should engineering test?
Agree a controlled test plan before production. The checklist below describes evidence to request; it is not a claim that every provider offers these mechanisms.
- Validate callback authentication against the exact signing scheme.
- Process a repeated event without duplicating a ledger entry.
- Recover a missing notification through an agreed lookup or replay path.
- Handle a delayed or superseded status without overwriting a newer decision.
- Link the invoice/order identifier to fees, payment amounts and settlement records.
- Record an exception with a named support owner and auditable resolution.
- Exercise wrong-network, late-payment, underpayment and refund scenarios where a safe test environment permits them.
Keep credentials and personal data out of application logs and public examples. Request a written incident and change-notification process from the supplier.
What belongs in the procurement pack?
| Buyer requirement | Evidence to request | Open question to resolve |
|---|---|---|
| Brand control | Screens, domains and disclosure rules | Which elements cannot be customized? |
| Onboarding | Responsibility and data-flow map | Who rejects, reviews and supports an applicant? |
| Funds and settlement | Money-flow diagram and sample statement | Who controls funds at each stage? |
| Refunds | Worked partial/full refund examples | Who approves and bears conversion/fee differences? |
| Reconciliation | Export schema and identifier mapping | How are corrections and unmatched payments resolved? |
| Support | Incident escalation and agreed service terms | Who responds to the merchant and end customer? |
| Contract scope | Entity, enabled products and exit terms | What happens to data, balances and integrations on termination? |
Put unresolved questions into the purchase decision rather than hiding them in a footnote. Geography-specific legal obligations, licensing, pricing and production eligibility are Verification Required; this guide makes no assurances about them.
Where should buyers continue their research?
For payment acceptance vendor research, see the existing NOWPayments, Coinbase Commerce and BitPay comparison. For customer fiat funding, start with the fiat on/off-ramp directory and its sourced onboarding dataset.
Send the journey you want to operate to contact@fluidrwa.com, including the customer geography, currencies, assets/networks and responsibilities your team wants to retain.
Sources and verification record
Checked October 7, 2026. These living company pages support the specific product descriptions above, not independent validation. Publication dates were not established.
- B2BINPAY: White Label Crypto Payment Gateway
- Cryptomus: Merchant API payment webhook
- Transak: Whitelabel API
Last updated and documentation checked: October 7, 2026. Reviewed by FluidRWA Research Team.
FAQ
Does a customizable checkout count as white-label?
Not by itself. Confirm the scope the provider explicitly offers and the contract's branding, operating and customer responsibilities. Changing colors or a logo does not establish a white-label service.
Is an API integration necessarily non-custodial?
No custody conclusion follows from the interface. Ask who controls keys and funds, where balances sit and what withdrawal authority applies. This guide does not establish custody for its named examples.
Can a white-label fiat ramp replace a merchant gateway?
Do not assume equivalence. Fiat-to-crypto funding and merchant payment acceptance are separate workflows. Verify invoice creation, payment confirmation, settlement, refunds and merchant onboarding independently.
What should a callback test prove?
As procurement guidance, test signature validation, duplicate processing, delayed events, lookup recovery and the link between an event and your order ledger. A callback alone should not be treated as evidence of bank settlement.
What must buyers verify about refunds?
Request the approval owner, recipient verification, currency and network, exchange-rate treatment, fee treatment and ledger linkage to the original payment. This is a checklist, not a claim that all providers implement those controls.
Are the named examples approved recommendations?
No. They illustrate different documented product scopes. Provider documentation is company evidence, not independent validation of performance, licensing, pricing or suitability. Production eligibility and contract terms remain Verification Required.
Discuss your payment requirements
Share the payment journey and responsibilities you need to own. Prefer email? contact@fluidrwa.com.