> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletconnect.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](/payments/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.
WalletKit integration for Android wallets.
WalletKit integration for iOS wallets.
WalletKit integration for React Native wallets.
WalletKit integration for Flutter wallets.
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.
Standalone Pay SDK for Android wallets.
Standalone Pay SDK for iOS wallets.
Standalone Pay SDK for React Native wallets.
Standalone Pay SDK for Flutter wallets.
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.
Integrate WalletConnect Pay using the Gateway API.
## Getting Started
To get started with WalletConnect Pay integration:
1. **Get a Project ID**: Create a wallet project at the [WalletConnect Dashboard](https://dashboard.walletconnect.com) to obtain your Project ID.
2. **Choose your integration approach**: Select either the WalletKit integration (if you already use WalletKit) or the standalone Pay SDK integration.
3. **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:
1. **Detect Payment Link**: Identify when a user scans or opens a WalletConnect Pay link
2. **Get Payment Options**: Fetch available payment options based on user's accounts
3. **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
4. **Get Required Actions**: Retrieve the signing actions for the selected payment option
5. **Sign Actions**: Sign the required permits/transactions using your wallet's signing infrastructure
6. **Confirm Payment**: Submit signatures 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.
## 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=` 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:
1. Call `getPaymentOptions` and display all available options to the user
2. When the user selects an option, check `selectedOption.collectData` — if it has a `url` field, data collection is required for that specific option
3. Display the URL in a WebView — the hosted form handles rendering, validation, and T\&C acceptance
4. The WebView communicates completion via JavaScript bridge messages (`IC_COMPLETE` / `IC_ERROR`)
5. When the WebView completes, proceed to confirm the payment — no `collectedData` needs 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:
* [WalletConnect Terms and Conditions](https://walletconnect.com/terms)
* [WalletConnect Privacy Policy](https://walletconnect.com/privacy)
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:
* [WalletConnect Terms and Conditions](https://walletconnect.com/terms)
* [WalletConnect Privacy Policy](https://walletconnect.com/privacy)
Yes. The hosted form accepts two optional appearance parameters on its URL:
* `theme=light` or `theme=dark` — sets the form's base color mode. Match it to your wallet's active mode.
* `themeVariables=` — 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](https://dashboard.walletconnect.com) 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.