Skip to main content
Wallets can make their app fully compatible with WalletConnect Pay to deliver a truly native payment experience. Users pay with crypto in real world scenarios with minimal friction while the wallet retains custody and full control over the user experience. WalletConnect provides two integration approaches for enabling WalletConnect Pay in your wallet:

​
Integration Options

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.

​
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.

​
API-First Integration

For wallets that prefer direct API integration without using an SDK, you can use the Gateway API directly.

API-first integration

Integrate WalletConnect Pay using the Gateway API.

​
Getting Started

To get started with WalletConnect Pay integration:
  1. Get a Project ID: Create a project at the WalletConnect Dashboard 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. Get Required Actions: Retrieve the signing actions for the selected payment option
  4. Sign Actions: Sign the required permits/transactions using your wallet’s signing infrastructure
  5. Collect User Data (if required): Display a WebView for the user to provide any required compliance information
  6. Confirm Payment: Submit signatures and complete the payment

​
Supported Networks

WalletConnect Pay currently supports USDC payments on the following networks:
NetworkChain ID
Ethereum1
Base8453
Optimism10
Polygon137
Arbitrum42161
Support for all EVM chains, Solana, and additional native and non-native assets is coming soon.

​
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=<base64-json> query parameter to the WebView URL. The required list from the collectDataAction.schema tells you which fields the form expects (e.g., fullName, dateOfBirth, pobAddress). The user will still see the form but with pre-populated fields, reducing friction.
When processing a payment:
  1. Check if response.collectData is present and has a url field
  2. If present, display the URL in a WebView — the hosted form handles rendering, validation, and T&C acceptance
  3. The WebView communicates completion via JavaScript bridge messages (IC_COMPLETE / IC_ERROR)
  4. 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 now support a WebView-based approach for collecting user information. When collectData.url is present in the payment options response, 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.
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: