Every PSP and fintech is having some version of the same meeting right now. A merchant asks about accepting stablecoins; a competitor quietly adds a "Pay with crypto" button; someone forwards the settlement numbers from a cross-border corridor. The question inside the company stops being whether to add crypto rails and becomes how — and that conversation usually happens four times, with four different people. This playbook walks through all four.
01 — The architecture conversation: where does it plug in?
The CTO's first worry is the right one: nobody wants a second payments stack. The white-label answer is that crypto arrives as a module behind your existing surface — one API and a branded checkout layer that sits inside the merchant portal you already run.
Merchant onboarding stays yours. Card acquiring and bank rails stay untouched. Settlement and reporting keep flowing through the systems you already reconcile. The crypto rail occupies exactly one socket: payment method in, settlement event out.
The non-custodial design is what makes the picture clean: funds move from the payer to the merchant's wallet without ever landing on your balance sheet, so the new rail adds a capability — not a treasury operation and not a pile of pooled customer funds to safeguard.
02 — The timeline conversation: four weeks, two lanes
The integration plan fits on one slide, split into your lane and the provider's:
Week one is scoping — which assets and chains, your fee card, your branding on the checkout. Week two is the actual integration: sandbox, webhooks, embedding the flow into your portal, with a solution engineer in the other lane. Week three wires compliance — your KYC tiers and alert routing on your side, screening and Travel Rule configuration on the provider's. Week four runs pilot merchants on real volume while go-live checks happen underneath. Traffic opens in week five.
The honest caveat: the four weeks assume your merchant portal has a normal plugin surface and your team can dedicate one engineer plus a product owner. Complex portals stretch the plan; none of it stretches into quarters.
03 — The compliance conversation: what's our exposure?
The compliance officer's questions have short answers in a non-custodial white-label setup. Custody exposure: none — you never hold customer funds, which keeps you out of the custody licensing regime in most jurisdictions. KYC/AML tooling: included — identity verification, sanctions and PEP screening, on-chain KYT monitoring, and Travel Rule support come as part of the built-in compliance layer. The program itself: still yours — risk policy, alert decisions, and reporting stay with your team, as they must.
That split is exactly the one your compliance team already runs for cards: infrastructure from vendors, accountability in-house. Crypto doesn't change the shape of it.
04 — The product conversation: what do merchants see?
They see you. The checkout carries your brand, the settlement report sits in the same portal, support goes through your existing channels — crypto appears to your merchants as one more payment method you switched on, not as a third-party product bolted to the side. That's the entire point of white label: the capability is CPAY's, the relationship is yours.
And the merchant-facing feature list is what closes deals: 100+ assets across 8 networks, settlement in stablecoins or crypto, no chargebacks on-chain, and checkout conversion that doesn't leak to an external redirect.
05 — The numbers conversation: does it pay?
Three numbers usually settle it. The infrastructure cost is a flat 0.5% per transaction — no minimums, no platform fee burning before volume arrives. Your margin is whatever you price above it, on a rail where merchants compare you to exchanges and standalone processors rather than to card interchange. And the third number is the quiet one: merchant retention — the accounts that don't leave for a competitor who added crypto first.
Four conversations, one decision. The stack stays yours, the funds never touch you, the timeline is measured in weeks — and the toggle, once built, is the kind of feature that never gets switched back off.
