Payment Request

Overview

A payment request is a structured instruction asking a payer or payment service to transfer a specified amount under defined currency, destination, and business terms. A request is not proof of authorization, transfer, confirmation, or settlement. It commonly includes amount, asset or pricing currency, payee, order reference, expiration, description, and callback context. Merchants must track the request with stable identifiers and reconcile actual received value against the obligation. Observability for Payment Request should record operation, version, principal, request ID, latency, retry count, error code, and final state without exposing secrets. A successful transport result from Payment Request should not be interpreted beyond the exact API state documented by the provider.

Payers should verify human-readable details before approval. Creators should validate amount precision, destination, asset, network, expiration, and business identity before issuing the request. The request can be represented as an API payload, invoice, link, QR code, wallet URI, or network message. Reusing one request for several orders can make allocation and refunds difficult unless the workflow explicitly supports that model. Details can expire, be altered, or target the wrong network. The Payment Request owner should publish stable error semantics and guidance on whether correction, retry, status lookup, or escalation is appropriate.

Changes to Payment Request should be checked against older clients, stored payloads, enum growth, default behavior, and retry assumptions.

Testing Payment Request should cover malformed input, denied access, rate limits, timeouts, duplicates, asynchronous completion, and version changes.

Data handled by Payment Request should use documented types, units, timestamp rules, nullable fields, and enum behavior to prevent silent interpretation errors.