There are two ways to build compliance into a crypto payment rail.
1: Every wallet does the same work, and the slowest setup defines the user experience.
2: The rail recognises what each wallet already knows, and the friction shrinks to whatever the wallet hasn't done.
WalletConnect Pay is built the second way, and the design choice shows up everywhere downstream.
What does WalletConnect Pay keep constant?
For the merchant and the PSP, the rail behaves like an APM, every time — regardless of which of the 700+ wallets on the WalletConnect network the user is paying from:
- Same payment intent
- Same lifecycle states (requires_action → processing → succeeded)
- Same reconciliation format
- Same settlement path; payout via regulated settlement and offramp partners in stablecoin (to wallet) or fiat (to bank account)
An orchestrator routing a transaction through WalletConnect Pay does not need different logic for a self-custodial wallet versus a neobank wallet versus an embedded wallet inside a gaming app. One rail, one integration, one normalised data model.
For the user, the shape of the checkout is the same in every case:
- Scan a QR
- Confirm in the wallet
- Done
A standardised user mental model is what makes this feel like a payment method, rather than 700 different crypto integrations stitched together.
What stays in the wallet?
The texture inside that shape.
- Unlock method. Passkey stays passkey. Password stays password. Biometric stays biometric.
- Design language. The wallet's own brand and visual identity show up in front of the user the way the wallet wants them to.
- Approval flow. The wallet decides how it asks the user to confirm.
The wallet is the part of the journey the user has chosen. If the rail forces a generic UI on top of every wallet, the wallet's reason for existing thins out. WalletConnect Pay was designed to sit beneath the wallet's identity, not in front of it.
What flexes?
The user-facing information capture, and only on first-time use. The compliance work itself runs every time, on every wallet. The data the rail has to collect is fixed by regulation:
- Full legal name
- Date of birth
- Country of residence (or place of birth, depending on jurisdiction)
- Wallet address
IP is checked at every payment for geo and sanctions screening. Not stored.
What flexes is where that data comes from and how much the user has to provide.
What runs every time, regardless of wallet. Travel Rule data transmission, IP and blocked-jurisdiction screening, and sanctions list checks (OFAC, UK HMT, EU Consolidated) all execute pre-payment on every transaction. A neobank user does almost nothing at first payment. The Travel Rule and sanctions work behind that payment is identical to what runs for a self-custodial wallet. What flexes is whether the user provides the data, or the wallet supplies it on their behalf.
The wallet decides the user-side experience. The rail does the regulatory work the same way every time.
What about wallets that haven't upgraded yet?
Every wallet on the WalletConnect network can accept a WalletConnect Pay payment from day one. Wallets that have not yet upgraded route through the fallback path:
- A controlled secure context at pay.walletconnect.com
- Returning users still skip the capture entirely
A PSP can turn the rail on without waiting for every wallet on the network to ship the upgrade. The native in-wallet experience is the path from "works" to "works beautifully," and arrives once the wallet upgrades.
What does this mean for PSPs and orchestrators?
A single APM-shaped rail that handles wallet heterogeneity for you:
- One set of merchant-side reconciliation rules
- One routing decision tree
- One integration across 700+ wallets
The wallet-side variance is absorbed entirely on the rail's side of the integration. The PSP receives the same Travel Rule fields, the same on-chain hash, the same payment status, the same settlement, regardless of which wallet the user paid from.
Conversion follows the same logic:
- Returning users always experience seconds.
- First-time setup ranges from near-zero to roughly two minutes, and the difference depends on the wallet, not the rail.
What should PSPs take from this?
- The checkout is constant. Across 700+ wallets, the rail behaves as a single APM. One payment intent, one reconciliation format, one routing tree. Wallet heterogeneity does not bleed into your integration.
- The user-side capture is variable. The compliance work behind it is not. First-time friction depends on what the wallet already holds. Neobank and exchange wallets approach zero seconds. Self-custodial wallets capture three fields once. Travel Rule and sanctions checks run identically every time. Returning users always experience seconds.
- Day-one viability does not depend on every wallet upgrading. Wallets that haven't yet upgraded route through the fallback path at pay.walletconnect.com. The native SDK experience is the path from "works" to "works beautifully."
When a payment rail spans 700+ wallets, the compliance work is the only place it can afford to be flexible. The checkout has to be one thing, every time. The compliance can be exactly as much work as the wallet hasn't already done.