Skip to main content
This documentation covers integrating WalletConnect Pay through WalletKit. This approach provides a unified API where Pay is automatically initialized alongside WalletKit, simplifying the integration for wallet developers.

Sample Wallet

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

Sample Wallet - Kotlin (WalletKit)

A reference Android wallet app demonstrating WalletConnect Pay via WalletKit.
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

  • Min SDK: 23 (Android 6.0)
  • WalletKit: 1.6.0+

Pre-Requisites

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

How to obtain a WCP 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 a WCP ID associated with your project.
  2. The Dashboard will now show the WCP ID associated with your project.
  3. Click on the three dots on the right of the WCP ID and select “Copy WCP ID”. You will be using this for your wallet’s WalletConnect Pay integration.
Copy WCP ID from WalletConnect Dashboard

Installation

First, add the required repositories to your project’s settings.gradle.kts or root build.gradle.kts:
Then add WalletKit to your app’s build.gradle.kts using the BOM (Bill of Materials):
WalletConnectPay is automatically included as a dependency of WalletKit.
Check the GitHub releases for the latest BOM version.

Initialization

WalletConnectPay is automatically initialized when you initialize WalletKit. No additional setup is required.
The Pay SDK is initialized internally with:
  • wcpId from your WalletConnect Project ID
  • packageName from your application context
For more details on WalletKit initialization, see the WalletKit Usage documentation.
Use WalletKit.Pay.isPaymentLink() to determine if a scanned URI is a payment link or a standard WalletConnect pairing URI:

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 Actions

Get the wallet RPC actions needed to complete the payment:
3

Sign Actions

Sign each required action using your wallet’s signing implementation:

Signing eth_signTypedData_v4

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.action.method (or rpc.method if you assign the action payload to a local variable) and dispatch to the appropriate handler. For full implementation guidance, see USDT support.
Signatures must be in the same order as the actions array.
4

Collect User Data (If Required)

Some payments require additional user information:

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

5

Confirm Payment

Submit signatures and finalize 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:

API Reference

WalletKit.Pay

The payment operations object within WalletKit.

Methods

Parameters

Wallet.Params.RequiredPaymentActions

Wallet.Params.ConfirmPayment

Data Models

Wallet.Model.PaymentOptionsResponse

Wallet.Model.PaymentInfo

Wallet.Model.PaymentOption

Wallet.Model.PaymentAmount

Wallet.Model.WalletRpcAction

Wallet.Model.CollectDataAction

Wallet.Model.ConfirmPaymentResponse

Wallet.Model.PaymentStatus

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 on the selected payment option 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 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.
  11. 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.