The WalletConnect Pay SDK allows wallet users to pay merchants using their crypto assets. The SDK handles payment option discovery, permit signing coordination, and payment confirmation while leveraging your wallet’s existing signing infrastructure.Documentation Index
Fetch the complete documentation index at: https://walletconnect-pay-docs-docs-add-ai-agent-sdk-section.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Sample Wallet
For a complete working example, check out our sample wallet implementation:Sample Wallet - Flutter
A reference Flutter wallet app demonstrating WalletConnect Pay integration.
Requirements
- Flutter 3.0+
- iOS 13.0+
- Android API 23+
Installation
Addwalletconnect_pay package to your pubspec.yaml or simply run:
Configuration
Initialize theWalletConnectPay client with your WCP ID and client ID or API key:
Configuration Parameters
| Parameter | Type | Required | Description |
|---|---|---|---|
apiKey | String? | No* | WalletConnect Pay API key |
appId | String? | No* | WCP ID |
clientId | String? | No | Client identifier |
baseUrl | String? | No | Base URL for the API (defaults to production) |
Either
apiKey or appId must be provided for authentication.Don’t have a project ID? Create one at the WalletConnect Dashboard by signing up and creating a new project.
Supported Networks & Tokens
WalletConnect Pay currently supports the following tokens and networks:| Token | Network | Chain ID | CAIP-10 Format |
|---|---|---|---|
| USDC | Arbitrum | 42161 | eip155:42161:{address} |
| USDC | Base | 8453 | eip155:8453:{address} |
| USDC | Polygon | 137 | eip155:137:{address} |
| USDC | Ethereum | 1 | eip155:1:{address} |
| USDC | Optimism | 10 | eip155:10:{address} |
| USDC | Monad | 143 | eip155:143:{address} |
| USDC | Celo | 42220 | eip155:42220:{address} |
| USDC | BSC | 56 | eip155:56:{address} |
| EURC | Ethereum | 1 | eip155:1:{address} |
| EURC | Base | 8453 | eip155:8453:{address} |
| USDT0 | Arbitrum | 42161 | eip155:42161:{address} |
| PYUSD | Ethereum | 1 | eip155:1:{address} |
| PYUSD | Arbitrum | 42161 | eip155:42161:{address} |
| USDG | Ethereum | 1 | eip155:1:{address} |
| USDT | Ethereum | 1 | eip155:1:{address} |
| USDT | Polygon | 137 | eip155:137:{address} |
| USDT | BSC | 56 | eip155:56:{address} |
Include accounts for all supported networks to maximize payment options for your users.
Payment Flow
The payment flow consists of four main steps: Get Options -> Get Actions -> Sign Actions -> Confirm PaymentGet Required Payment Actions
Get the required wallet actions (e.g., transactions to sign) for a selected payment option:
Payment options may include multiple actions with different RPC methods. For example, a Permit2 payment where the user lacks sufficient allowance returns two actions: an
eth_sendTransaction to approve the token allowance, followed by an eth_signTypedData_v4 to sign the Permit2 transfer. Your wallet must check action.walletRpc.method and dispatch to the appropriate handler. For full implementation guidance, see USDT support.Collect User Data (If Required)
Some payments may require additional user data. Check for
collectData in the payment options response:WebView-Based Data Collection
When a payment requires user information (e.g., for Travel Rule compliance), the SDK returns acollectData field on individual payment options. Each option may independently require data collection — some options may require it while others don’t.Recommended Flow (Per-Option)
The recommended approach is to display all payment options upfront, then handle data collection only when the user selects an option that requires it:- Call
getPaymentOptionsand display all available options to the user - Show a visual indicator (e.g., “Info required” badge) on options where
option.collectDatais present - When the user selects an option, check
selectedOption.collectData - If present, open
selectedOption.collectData.urlin a WebView within your wallet - Optionally append a
prefill=<base64-json>query parameter with known user data (e.g., name, date of birth, address). Use proper URL building to handle existing query parameters. - Listen for JS bridge messages:
IC_COMPLETE(success) orIC_ERROR(failure) - On
IC_COMPLETE, proceed toconfirmPayment()without passingcollectedData— the WebView submits data directly to the backend
Decision Matrix
Response collectData | option.collectData | Behavior |
|---|---|---|
| present | present | Option requires IC — use option.collectData.url |
| present | null | Option does NOT require IC (others might) — skip IC for this option |
null | null | No IC needed for any option |
The
collectData also includes a schema field — a JSON schema string describing the required fields. The required list in this schema tells you which fields the form expects. Wallets can use these field names as keys when building the prefill JSON object. For example, if the schema’s required array contains ["fullName", "dob", "pobAddress"], you can prefill with {"fullName": "...", "dob": "...", "pobAddress": "..."}.The top-level
collectData on the payment options response is still available for backward compatibility. However, the per-option collectData is the recommended approach as it provides more granular control over the flow.WebView Message Types
The WebView communicates with your wallet through JavaScript bridge messages. The message payload is a JSON string with the following structure:| Message Type | Payload | Description |
|---|---|---|
IC_COMPLETE | { "type": "IC_COMPLETE", "success": true } | User completed the form successfully. Proceed to payment confirmation. |
IC_ERROR | { "type": "IC_ERROR", "error": "..." } | An error occurred. Display the error message and allow the user to retry. |
Platform-Specific Bridge Names
| Platform | Bridge Name | Handler |
|---|---|---|
| Kotlin (Android) | AndroidWallet | @JavascriptInterface onDataCollectionComplete(json: String) |
| Swift (iOS) | payDataCollectionComplete | WKScriptMessageHandler.didReceive(message:) |
| Flutter | ReactNativeWebView (injected via JS bridge) | JavaScriptChannel.onMessageReceived |
| React Native | ReactNativeWebView (native) | WebView.onMessage prop |
WebView Implementation
WhencollectData.url is present, display the URL in a WebView using the webview_flutter package (v4.10.0+). Add it to your pubspec.yaml:
Complete Example
Here’s a complete implementation example:API Reference
WalletConnectPay
The main class for interacting with the WalletConnect Pay SDK.Constructor
Methods
| Method | Description |
|---|---|
Future<bool> init() | Initializes the SDK. Returns true on success or throw PayInitializeError on error |
Future<PaymentOptionsResponse> getPaymentOptions({required GetPaymentOptionsRequest request}) | Retrieves available payment options |
Future<List<Action>> getRequiredPaymentActions({required GetRequiredPaymentActionsRequest request}) | Gets the required wallet actions for a selected option (to be called if the selected option does not have actions included) |
Future<ConfirmPaymentResponse> confirmPayment({required ConfirmPaymentRequest request}) | Confirms a payment |
Models
GetPaymentOptionsRequest
PaymentOptionsResponse
PaymentResultInfo
PaymentInfo
PaymentOption
ConfirmPaymentRequest
ConfirmPaymentResponse
PaymentStatus
Action & WalletRpcAction
CollectDataAction
Error Handling
The SDK throws specific exception types for different error scenarios. All errors extend the abstractPayError class, which itself extends PlatformException:
| Exception | Description |
|---|---|
PayInitializeError | Initialization failures |
GetPaymentOptionsError | Errors when fetching payment options |
GetRequiredActionsError | Errors when getting required actions |
ConfirmPaymentError | Errors when confirming payment |
code: Error codemessage: Error messagedetails: Additional error detailsstacktrace: Stack trace
Example Error Handling
Best Practices
-
Initialize once: Call
init()only once, typically during app startup -
Account Format: Always use CAIP-10 format for accounts:
eip155:{chainId}:{address} - Multiple Chains: Provide accounts for all supported chains to maximize payment options
- Signature Order: Maintain the same order of signatures as the actions array
- Error Handling: Always handle errors gracefully and show appropriate user feedback
- Loading States: Show loading indicators during API calls and signing operations
-
Expiration: Check
paymentInfo.expiresAtand warn users if time is running low -
User Data: Only collect data when
collectDatais present in the response and you don’t already have the required user data. If you already have the required data, you can submit this without collecting from the user. You must make sure the user accepts WalletConnect Terms and Conditions and Privacy Policy before submitting user information to WalletConnect. -
WebView Data Collection: When
collectData.urlis present, display the URL in a WebView usingwebview_flutterrather than building native forms. The WebView handles form rendering, validation, and T&C acceptance.