Skip to main content
This documentation covers integrating WalletConnect Pay through ReownWalletKit. This approach provides a unified API where Pay is automatically initialized alongside WalletKit, simplifying the integration for wallet developers.
Using AI for Integration? If you’re using an AI IDE or assistant to help with integration, you can provide it with our comprehensive AI integration prompt for better context and guidance.

Requirements

  • Flutter 3.0+
  • iOS 13.0+
  • Android API 23+
  • ReownWalletKit

Pre-Requisites

In order to use your WalletConnect Pay, you need to obtain an App ID for your project from the WalletConnect Dashboard.

How to obtain an App ID

  1. Navigate to the WalletConnect Dashboard.
  2. Select the project that is associated with your wallet (as in, the projectId that is being used for your wallet’s WalletConnect integration).
Select the project on WalletConnect Dashboard
  1. Click on the “Get Started” button to get an App ID associated with your project.
  2. The Dashboard will now show the App ID associated with your project.
  3. Click on the three dots on the right of the App ID and select “Copy App ID”. You will be using this for your wallet’s WalletConnect Pay integration.
Copy App ID from WalletConnect Dashboard

Installation

Add reown_walletkit to your pubspec.yaml:
Then run:
WalletConnectPay is automatically included as a dependency of ReownWalletKit.
Check the pub.dev page for the latest version.

Initialization

The WalletConnectPay client is automatically initialized during ReownWalletKit.init(). No additional setup is required.

Accessing the Pay Client

You can access the WalletConnectPay instance directly:
Detect if a URI is a payment link before processing:

Payment Flow

The payment flow consists of five main steps: Detect Payment Link -> Get Options -> Get Actions -> Sign Actions -> Confirm Payment
1

Get Payment Options

Retrieve available payment options for a payment link:
2

Get Required Payment Actions

Get the required wallet actions for a selected payment option:
3

Collect User Data (If Required)

Some payments may require additional user data:

WebView-Based Data Collection

When a payment requires user information (e.g., for Travel Rule compliance), the SDK returns a collectData field on individual payment options. Each option may independently require data collection — some options may require it while others don’t.The recommended approach is to display all payment options upfront, then handle data collection only when the user selects an option that requires it:
  1. Call getPaymentOptions and display all available options to the user
  2. Show a visual indicator (e.g., “Info required” badge) on options where option.collectData is present
  3. When the user selects an option, check selectedOption.collectData
  4. If present, open selectedOption.collectData.url in a WebView within your wallet
  5. 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.
  6. Listen for JS bridge messages: IC_COMPLETE (success) or IC_ERROR (failure)
  7. On IC_COMPLETE, proceed to confirmPayment() without passing collectedData — the WebView submits data directly to the backend

Decision Matrix

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.
When using the WebView approach, do not pass collectedData to confirmPayment(). The WebView handles data submission directly.

WebView Message Types

The WebView communicates with your wallet through JavaScript bridge messages. The message payload is a JSON string with the following structure:

Platform-Specific Bridge Names

4

Confirm Payment

Confirm the payment with signatures and optional collected data:

WebView Implementation

When collectData.url is present, display the URL in a WebView using webview_flutter (v4.10.0+). Add dependencies:

Complete Example

Here’s a complete example of processing a payment:

Direct Access

You can also access the underlying WalletConnectPay instance directly if needed:

API Reference

ReownWalletKit Pay Methods

Models

GetPaymentOptionsRequest

PaymentOptionsResponse

PaymentResultInfo

PaymentInfo

PaymentOption

ConfirmPaymentRequest

ConfirmPaymentResponse

PaymentStatus

CollectDataAction

Error Handling

The SDK throws specific exception types for different error scenarios. All errors extend the abstract PayError class, which itself extends PlatformException:
All errors include:
  • code: Error code
  • message: Error message
  • details: Additional error details
  • stacktrace: Stack trace

Example Error Handling

Best Practices

  1. Use WalletKit Integration: If your wallet already uses WalletKit, prefer this approach for automatic configuration
  2. Use isPaymentLink() for Detection: Use the utility method instead of manual URL parsing for reliable payment link detection
  3. Account Format: Always use CAIP-10 format for accounts: eip155:{chainId}:{address}
  4. Multiple Chains: Provide accounts for all supported chains to maximize payment options
  5. Signature Order: Maintain the same order of signatures as the actions array
  6. Error Handling: Always handle errors gracefully and show appropriate user feedback
  7. Loading States: Show loading indicators during API calls and signing operations
  8. Expiration: Check paymentInfo.expiresAt and warn users if time is running low
  9. User Data: Only collect data when collectData is 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.
  10. WebView Data Collection: When collectData.url is present, display the URL in a WebView using webview_flutter rather than building native forms. The WebView handles form rendering, validation, and T&C acceptance.

Examples

For a complete example implementation with UI components showing the full payment flow, see the reown_walletkit example. The example demonstrates:
  • Payment link detection and processing
  • Payment options retrieval with UI
  • Data collection for compliance (KYB/KYC)
  • Payment details display
  • Transaction signing and confirmation
  • Payment status polling and result display