--- title: "Payment Method Group" description: "TrUAPI method group for payment flows, including the standard Balances transfer surface and the Pocket peer-to-peer flow for Product payments." categories: "Apps, Reference" url: "https://developers.polkadot.com/reference/apps/protocol/truapi/payment/" word_count: 345 token_estimate: 514 version_hash: "sha256:7462edb5b6119c92f736c029eb9ab2c5f6e0ef9ece3619620192847ecf7d14ce" last_updated: "2026-11-13T11:04:04+00:00" --- # Payment ## Introduction The Payment method group lets a Product accept or initiate payments. Payments are signed transactions like any other transaction, but this group collects the two payment shapes a Product is most likely to need, the standard `Balances.transfer_keep_alive` flow and the personhood-aware Pocket flow. For most Product use cases, this group is consumed through `@parity/product-sdk-tx` and helpers in `@parity/product-sdk-utils` (formatting, validation), with the same `signAndSubmit` round trip every other signed call goes through. ## Conceptual Contract The group covers: - **Building a payment request**: The Product encodes what a merchant is asking for, including recipient, amount, and optional memo, into a payload the payer's Product can parse and pre-fill into a transfer form. No on-chain interaction happens at request-build time; the request is an application-layer payload. - **Constructing a transfer extrinsic**: Given a validated recipient and a planck-denominated amount, building a `Balances.transfer_keep_alive` (or `transfer_allow_death` when the sender intends to drain the account) ready to sign. - **Submitting and watching the payment**: The Product passes the extrinsic through the standard Signing surface and observes status transitions of `signing`, `broadcasting`, `in-block`, and `finalized`. - **Pocket variant**: Pocket is personhood-aware and two-sided. The sender acts on Desktop, the receiver acts on the App, and the receiver explicitly accepts or declines. See [Pocket on Polkadot Desktop](/reference/apps/hosts/polkadot-desktop/pocket/) for the conceptual model. The Payment group does not introduce new signing semantics. Every payment-side transaction still routes through the per-transaction approval flow on the paired App. :::caution[Provisional] The Pocket-specific TrUAPI methods (whether and how a Product can initiate a Pocket transfer programmatically versus relying on Host UI), payment-request URL formats as a canonical wire format, and any asset-aware extensions (multi-asset transfers, pUSD-specific calls) are still being finalized. ::: ## Where to Go Next
- **Pocket on Polkadot Desktop** --- The Pocket send flow's conceptual model and how it pairs with the App-side recipient view. [→ Reference](/reference/apps/hosts/polkadot-desktop/pocket/)