WalletConnect Pay

• Name: WalletConnect Pay
• URL: https://docs.walletconnect.com/payments/overview
• Category: crypto payments interoperability layer / PSP-compatible wallet payments control plane / wallet-and-checkout integration infrastructure
• Tags: ethereum-ecosystem
• Summary: WalletConnect Pay is a payment-acceptance and interoperability layer for PSPs, merchants, and wallets. Keep this note on the payment flow itself: wallet routing, checkout execution, compliance handling, and settlement-path coordination. The broader operator and packaging boundary now matters separately too, because the easiest merchant / wallet integration path is still part of the wider reown shell rather than a neutral payments baseline.
• What it does:
  • Lets PSPs, acquirers, and merchants add crypto and stablecoin acceptance to existing checkout and point-of-sale flows without redesigning the rest of the payment stack
  • Uses WalletConnect-compatible QR or payment-link flows so customers can pay from supported wallets while still choosing asset and network at checkout
  • Provides wallet-side integrations through existing WalletKit support, standalone Pay SDKs, or direct API-first integration paths
  • Handles option discovery, signing-action retrieval, optional compliance information capture, and payment confirmation as a structured flow for wallet developers
  • Supports ecommerce and in-store payment use cases with settlement paths that can end in crypto or fiat, depending on the PSP stack
  • Exposes an experimental walletconnect-pay CLI and programmatic client through the agent-sdk, allowing terminal or agent-driven payment creation, status checks, and checkout flows
• Key claims:
  • The overview page says WalletConnect Pay provides a “complete end-to-end crypto payment solution” that fits directly into an existing PSP stack, which is the strongest top-level categorization signal surfaced in this pass
  • The same docs say the product aligns with common payment-compliance requirements and keeps familiar operational controls such as transaction-information capture and screening steps
  • The wallet-integration docs say one integration connects a wallet to a global network of PSPs and merchants across ecommerce and point of sale, while WalletConnect Pay handles execution, compliance, settlement, and gas
  • The wallet docs also show three integration models—WalletKit, standalone SDK, and API-first—plus a common flow of payment-link detection, option retrieval, action signing, optional data collection, and confirmation, which makes the product look like infrastructure rather than a one-off UX feature
  • The supported-assets table and FAQs show that token/network choice and per-option information capture are first-class concerns, and that Travel Rule-style personal-information collection can be triggered through a hosted WebView flow when required
  • The ecommerce docs explicitly market “any wallet, any asset, one checkout flow” and emphasize compatibility with existing checkout and operations workflows rather than a merchant rebuilding payments from scratch
  • The agent-sdk README exposes an experimental walletconnect-pay CLI with proxy mode, direct API mode, merchant payment creation, and information-capture flags, which extends the payment layer into terminal and agent workflows rather than limiting it to browser checkout alone
• Whitepaper: No canonical standalone WalletConnect Pay whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official WalletConnect Pay docs corpus and the agent-sdk repository materials; see ../whitepapers/walletconnect-pay-primary-sources-2026-05-03.md.
• Sources:
  • https://docs.walletconnect.com/payments/overview
  • https://docs.walletconnect.com/payments/wallets/overview
  • https://docs.walletconnect.com/payments/ecommerce/overview
  • https://docs.walletconnect.com/payments/for-users
  • https://github.com/WalletConnect/agent-sdk/blob/main/README.md

Internal linkages

• Parent stack: walletconnect.
• Company boundary for packaging, partner composition, and the broader app-facing operator shell: reown.
• Best contrast point: open-payments.

Protocol / company boundary

• Keep projects/walletconnect-pay on the payment workflow itself: checkout orchestration, wallet routing, information capture, confirmation flow, and settlement-path design.
• Use reown when the sharper question is who packages this with the rest of the WalletConnect / AppKit stack, controls the easiest integration and onboarding path for wallets or PSPs, and defines the broader commercial and operator shell around the product.
• That split matters because the payment flow can look protocol-like at the edge while adoption, defaults, and partner packaging still arrive through one named company boundary.

Control surface

• Power sits in PSP and wallet admission, supported asset-and-network policy, checkout option discovery, compliance-information capture, signing-action retrieval, and the settlement path the operator allows behind the payment prompt.

• Keep the company layer visible too: reown is where packaging, partner composition, and the default integration shell around this payment surface become easier to analyze.

• Read it as a wallet-payment operating layer, not as a neutral protocol baseline.

• Last reviewed: 2026-08-10 UTC