Skip to main content
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.

Sample Wallet

For a complete working example, check out our sample wallet implementation:

Sample Wallet - Kotlin

A reference Android wallet app demonstrating WalletConnect Pay integration.

Requirements

  • Min SDK: 23 (Android 6.0)
  • Target SDK: 36
  • JVM Target: 11

Installation

Add the WalletConnect Pay SDK to your project’s build.gradle.kts file:
The version shown above may not be the latest. Check the GitHub releases for the most recent version.

JNA Dependency Configuration

If you encounter JNA-related errors (e.g., UnsatisfiedLinkError or class loading issues), explicitly configure the JNA dependency:

Configuration

Initialize the SDK in your Application class or before any payment operations:

Configuration Parameters

*Either apiKey or appId is required for authentication.
Don’t have a project ID? Create one at the WalletConnect Dashboard by signing up and creating a new project.
The SDK will throw IllegalStateException if already initialized. Call initialize() only once.

Supported Networks & Tokens

WalletConnect Pay currently supports the following tokens and networks: All account addresses must be provided in CAIP-10 format: eip155:<chainId>:<address>
Include accounts for all supported networks to maximize payment options for your users.

Payment Flow

The payment flow consists of five main steps: Get Options -> Get Actions -> Sign Actions -> Collect Data (if required) -> Confirm Payment
1

Initialize the SDK

2

Get Payment Options

When a user scans a payment QR code or opens a payment link, fetch available payment options:
3

Get Required Actions

After the user selects a payment option, get the wallet RPC actions needed to complete the payment:
4

Sign Actions

Sign each action using your wallet’s signing implementation:
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 rpc.method (or action.action.method) and dispatch to the appropriate handler. For full implementation guidance, see USDT support.
Signatures must be in the same order as the actions array.
5

Collect User Data (If Required)

Some payments require collecting additional user information. Check for collectData on the selected payment option:

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

6

Confirm Payment

Submit the signatures and collected data to complete the payment:

WebView Implementation

When a selected option has collectData.url present, display the URL in a WebView. The WebView handles form rendering, validation, and T&C acceptance.

Complete Example

Here’s a complete implementation example using a ViewModel:

API Reference

WalletConnectPay

Main entry point for the Pay SDK (singleton object).

Properties

Methods

Data Models

Pay.PaymentOptionsResponse

Pay.PaymentInfo

Pay.PaymentOption

Pay.Amount

Pay.WalletRpcAction

Pay.RequiredAction

Pay.CollectDataAction

Pay.ConfirmPaymentResponse

Pay.PaymentStatus

Error Handling

The SDK provides typed errors for different failure scenarios:

GetPaymentOptionsError

GetPaymentRequestError

ConfirmPaymentError

Example Error Handling

Best Practices

  1. Initialize once: Call initialize() only once, typically in Application.onCreate()
  2. Account Format: Always use CAIP-10 format for accounts: eip155:{chainId}:{address}
  3. Multiple Chains: Provide accounts for all supported chains to maximize payment options
  4. Signature Order: Maintain the same order of signatures as the actions array
  5. Error Handling: Always handle errors gracefully and show appropriate user feedback
  6. Thread Safety: Events are delivered on IO dispatcher; update UI on main thread
  7. WebView Data Collection: When selectedOption.collectData?.url is present, display the URL in a WebView rather than building native forms. The WebView handles form rendering, validation, and T&C acceptance.
  8. Per-Option Data Collection: When displaying payment options, check each option’s collectData field. 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 — use the option’s collectData.url which is already scoped to that option’s account.