WalletConnect Pay - Wallet Integration
Your users hold crypto and stablecoins. WalletConnect Pay gives them somewhere to spend it.
One integration connects your wallet to a global network of PSPs and merchants — online and in-store. You control the experience. WalletConnect Pay handles the rest: payment execution, compliance, settlement, and gas.
What's included
- Consistent, compliant payment flows across ecommerce and point of sale
- Interchange revenue for your wallet on every eligible transaction, settled in $WCT
- Cashback in $WCT for your users on every purchase
- Check Token and Chain coverage for supported tokens and chains
WalletConnect provides three integration approaches for enabling WalletConnect Pay in your wallet:
Integration Options
Integrate using the Wallet SDK (Recommended)
If your wallet already uses the WalletConnect Wallet SDK (WalletKit), WalletConnect Pay is automatically available when you initialize WalletKit. This is the recommended approach as it provides a unified API and automatic configuration.
Kotlin
WalletKit integration for Android wallets.
Swift
WalletKit integration for iOS wallets.
React Native
WalletKit integration for React Native wallets.
Flutter
WalletKit integration for Flutter wallets.
Web/Node.js
WalletKit integration for Web/Node.js wallets.
Standalone Integration
For wallets that don't currently use the WalletConnect Wallet SDK, you can integrate the standalone Pay SDK directly. This approach requires configuring the SDK with your WalletConnect Project ID.
Kotlin
Standalone Pay SDK for Android wallets.
Swift
Standalone Pay SDK for iOS wallets.
React Native
Standalone Pay SDK for React Native wallets.
Flutter
Standalone Pay SDK for Flutter wallets.
Web/Node.js
Standalone Pay SDK for Web/Node.js wallets.
API-First Integration
For wallets that prefer direct API integration without using an SDK, you can use the Gateway API directly.
WebView Integration
For apps that want to embed the full WalletConnect Pay checkout UI inside a native WebView — without redirecting to an external browser. The hosted checkout handles everything; your app supplies two query parameters and listens for bridge messages.
Getting Started
To get started with WalletConnect Pay integration:
-
Get a Project ID: Create a wallet project at the WalletConnect Dashboard to obtain your Project ID.
-
Choose your integration approach: Select either the WalletKit integration (if you already use WalletKit) or the standalone Pay SDK integration.
-
Follow the platform-specific guide: Use the documentation for your platform to implement the payment flow.
Payment Flow Overview
Regardless of which integration approach you choose, the payment flow follows the same pattern:
- Detect Payment Link: Identify when a user scans or opens a WalletConnect Pay link
- Get Payment Options: Fetch available payment options based on user's accounts
- Collect User Data (if required for selected option): If the selected payment option requires compliance information, display a WebView for the user to provide it. This must happen before fetching the required actions — the WebView submits the data directly to the backend
- Get Required Actions: Retrieve the signing actions for the selected payment option
- Sign Actions: Sign the required permits/transactions using your wallet's signing infrastructure
- Confirm Payment: Submit the wallet RPC results (
data) and complete the payment
Recommended Implementation
For best user experience, follow the recommended implementation below.
Testing
Test your WalletConnect Pay integration with the Point-of-Sale app in the WalletConnect Dashboard. To enable the app, configure a mock-merchant recipient address. Payments will arrive to this address and you won't lose any testing funds.
On Solana, payment options for non-native tokens only appear once this address has an associated token account (ATA) for that token. The easiest way to create one is to send a small amount of the token to this address — the transfer covers the SOL needed to create the account. Alternatively, send a create-account transaction and pay for it with SOL.
Earn Revenue
Wallets can earn interchange-like revenue on eligible WalletConnect Pay payments. To activate, make sure to complete a successful payment with your integration, then submit the Form found in the WalletConnect Dashboard. We will review the submission and confirm the results to the submitted contact email.
User Information FAQs
No. The process is optimised so users don't have to re-enter information for each transaction. Once collected, the information will be reused.
Wallets that already have verified user PII (e.g. a neobank, a card issuing wallet) can prefill the WebView form by appending a ?prefill=<base64url-json> query parameter to the WebView URL. The required list from the collectDataAction.schema tells you which fields the form expects (e.g., fullName, dob, pobAddress). The user will still see the form but with pre-populated fields, reducing friction.
When processing a payment:
- Call
getPaymentOptionsand display all available options to the user - When the user selects an option, check
selectedOption.collectData— if it has aurlfield, data collection is required for that specific option - Display the URL in a WebView — the hosted form handles rendering, validation, and T&C acceptance
- The WebView communicates completion via JavaScript bridge messages (
IC_COMPLETE/IC_ERROR) - When the WebView completes, proceed to confirm the payment — no
collectedDataneeds to be passed since the WebView submits data directly
WalletConnect Pay complies with Travel Rule regulations to ensure the payment flow is scalable and future-proof across all regions. This requires capturing some user information like name and date of birth.
The WebView-based data collection form handles Terms & Conditions and Privacy Policy acceptance as part of the form flow. The user must accept these before the form can be submitted.
SDKs support a WebView-based approach for collecting user information. When selectedOption.collectData.url is present on a payment option, wallets display this URL in a WebView instead of building native forms. The hosted form handles:
- Form rendering and field validation
- Terms & Conditions and Privacy Policy acceptance
- Data submission directly to the backend
The WebView communicates with the wallet via JavaScript bridge messages (IC_COMPLETE when done, IC_ERROR on failure). See the platform-specific documentation for implementation details.
We strongly recommend using the WebView-based flow over building custom native UI. Data collection requirements are driven by regulation and can evolve. The hosted WebView form is maintained and updated centrally so that wallets can automatically pick up changes.
No. Information capture (IC) is per-option — some payment options may require it while others don't. Each payment option has its own collectData field. When option.collectData is present, the user must complete data collection before confirming that option. When it's null, no IC is needed for that option.
Wallets should display all options upfront and show a visual indicator (e.g., "Info required" badge) on options that require data collection. Only open the WebView when the user selects an option with collectData present.
Yes, with a caveat.
Wallets that choose to implement custom UI assume responsibility for keeping their forms in sync with these changes. When changes are rolled out, wallets must implement them immediately. If the provided data is not what is requested, users in the relevant jurisdiction(s) will be unable to pay until the custom integration is updated. The WebView approach eliminates this overhead and ensures a consistent, up-to-date experience with minimal integration effort.
Wallets also must ensure the user has accepted:
The required user information can be sent to WalletConnect using schema in the collect_data object.
We strongly recommend using the WebView-based flow over building custom native UI. Data collection requirements are driven by regulation and can evolve. The hosted WebView form is maintained and updated centrally so that wallets can automatically pick up changes.
Yes.
Wallets can pre-fill user information and it will be shown in the WebView form.
If wallets choose to skip the WebView form, they must ensure the user has accepted:
Yes. The hosted form accepts two optional appearance parameters on its URL:
theme=lightortheme=dark— sets the form's base color mode. Match it to your wallet's active mode.themeVariables=<base64url>— overrides design tokens (font, font size, some colors, button border radius, and input border radius). Generate and export this value from the WalletConnect Pay Dashboard and append it to the form URL verbatim.
Both are optional and independent — when omitted, the form uses its default styling. See your platform's integration guide for the URL-building code.