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 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.

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