Payment Requests

A Z00Z payment request is a receive-intent surface. It helps a sender and receiver coordinate a handoff, but it is not settled ownership, not a permanent public address, and not a guarantee that every business condition behind the transfer is true. A request is useful because it gives wallets a scoped place to carry receiver material, amount or object intent, policy hints, expiry, and local validation expectations before checkpointed settlement.

This page is implementation-facing, but it is not a reference for a shipped local payment-request SDK in this website repository. Treat the object names as corpus-backed architecture unless a future implementation reference provides exact code signatures.

Core Terms

Term	Builder meaning	Boundary
`ReceiverCard`	Receiver-facing routing and approval input for a receive flow	Not a permanent public account address
`PaymentRequest`	Scoped receive-intent object with parameters for a specific handoff	Not final settlement proof
Acceptance	Wallet-local decision that a request or incoming object is understandable and acceptable	Not necessarily checkpoint finality
Voucher transfer	Movement of conditional value under policy	Not clean native cash unless redeemed into clean output
Refund	Explicit policy branch for rejected, expired, or partially redeemed conditional value	Not arbitrary clawback
Quarantine	Wallet treatment for unknown, unsafe, or unsupported object policies	Not permanent confiscation
Conflict handling	Proof, lock, slash, compensation, or unlock flow when misuse is detected	Target architecture unless implementation evidence exists

The main design rule is that receiver convenience must not recreate a public account table. A request may be shareable. It should not become a stable public identity for all future payments.

Request Sequence

sequenceDiagram box rgb(227,242,253) Public API / User participant ReceiverWallet as Receiver wallet end box rgb(227,242,253) Public API / User participant SenderWallet as Sender wallet end box rgb(255,243,224) Infrastructure / Runtime participant Publication as Publication path end box rgb(243,229,245) Domain logic participant Checkpoint as Checkpoint settlement end ReceiverWallet->>ReceiverWallet: Build scoped ReceiverCard or PaymentRequest ReceiverWallet-->>SenderWallet: Share request material SenderWallet->>SenderWallet: Validate scope, policy, expiry, and receiver data SenderWallet->>SenderWallet: Prepare package or voucher transfer SenderWallet-->>ReceiverWallet: Present candidate handoff ReceiverWallet->>ReceiverWallet: Accept, reject, or quarantine locally SenderWallet->>Publication: Submit package when ready Publication->>Checkpoint: Include in checkpoint-facing evidence Checkpoint-->>ReceiverWallet: Settlement state becomes authoritative

The sequence shows why request state names matter. “Shared,” “accepted,” “published,” and “settled” are not the same state. Wallet copy and APIs should not flatten them.

Request Intent

Request intent should answer a narrow set of questions:

Who is the receiver surface for this handoff?
What object family is expected: clean asset, voucher, right, claim, or future capability object?
Is the request scoped by amount, merchant, issuer, time, policy, or allowed action?
Which wallet-local checks are required before accepting the handoff?
What should happen if the request is expired, unsupported, replayed, or mismatched?

The request should carry enough structure for wallets to warn users. It should not carry an open-ended instruction like “send anything here forever.” That is how a receiver-native model drifts back toward a public address model.

Clean Payment Versus Voucher Transfer

The Assets/Rights/Vouchers paper makes the critical distinction. Clean cash payment means the receiver gets final spendable value. Voucher transfer means the receiver gets conditional value. The wallet must not display both as the same unrestricted balance.

Flow	Receiver should understand
Clean asset payment	“I received final spendable value once settlement accepts it”
Voucher transfer	“I received a conditional value claim with policy, redeem, refund, or expiry rules”
Right transfer	“I received authority to perform a bounded action, not value itself”
Claim flow	“I may materialize a recipient-bound output under claim-specific replay and proof rules”

This distinction is not cosmetic. If vouchers look like cash, users may accept conditional objects without knowing the policy. If rights look like value, wallets may count authority as spendable money. If claim flows look like arbitrary minting, docs will misrepresent the replay and source-boundary model.

Acceptance

Acceptance is a wallet-local and policy-aware step. The receiver may decide that the request or incoming object is understandable, supported, and appropriate for the context. That does not mean public settlement has occurred.

Wallet acceptance checks should include:

Check	Why it matters
Object family	Avoids treating voucher or right objects as clean cash
Policy availability	Avoids accepting an object whose lifecycle cannot be interpreted
Expiry and replay context	Prevents stale or reused requests from looking valid
Receiver material	Confirms the request was meant for the current receive flow
Disclosure expectations	Warns if the flow will require audit or regulated review
Trust tier	Distinguishes protocol-native, issuer, custody, service, or app-layer assumptions

The wallet can accept locally before settlement because Z00Z supports wallet-local possession and local interpretation. It must still show the user when finality remains pending.

Refund Semantics

Refund is safe only when it is explicit. A voucher may define refund after rejection, refund after expiry, refund of remaining value after partial redeem, or a source-context return for restricted treasury or budget funds. That is very different from a hidden sender power to claw back ordinary cash whenever desired.

A request or voucher API should therefore expose refund state in policy terms:

Refund case	Safe framing
Receiver rejects before acceptance	Return according to the declared voucher policy
Voucher expires unused	Refund remaining value to the declared source context
Partial redeem leaves remainder	Preserve redeemed value and route only remaining value by policy
Policy unsupported	Quarantine or reject rather than silently treating as cash
Fraud or conflict path	Use liability or dispute evidence, not arbitrary UI reversal

If refund semantics are ambiguous, wallets should not hide that ambiguity. They should mark the object as conditional or unsupported until policy evidence is clear.

Quarantine And Unknown Policy

Wallet quarantine is the safe state for objects that are well-formed enough to inspect but not safe enough to count as spendable value. A voucher policy may be missing. A request may reference an unsupported action pool. A right may target an object family the wallet does not understand. A trust tier may depend on an external issuer or service that the user has not accepted.

Quarantine should be understandable:

do not count the object as ordinary spendable balance;
keep enough local evidence to explain why it is blocked;
give the user a path to reject, disclose, inspect policy, or wait for support from a trusted implementation;
do not leak the object broadly to support services by default;
do not auto-redeem unknown policy objects just to improve UX.

This is a wallet safety feature. It protects receivers from dirty-cash confusion and from object families that the local wallet cannot honestly interpret.

Conflict Handling And Linked Liability

Request and voucher flows can interact with liability when delayed, offline, autonomous, or conditional behavior creates misuse risk. The linked-liability model keeps honest-case responsibility hidden and activates narrower evidence only when conflict is proven.

For payment requests, that means conflict handling should stay scoped:

Conflict	Correct direction
Duplicate or stale request use	Reject or quarantine under replay and freshness checks
Conflicting offline spend	Use fraud-proof and liability activation paths where designed
Voucher misuse	Apply policy-defined lock, refund, slash, or compensation branches
Ambiguous service dispute	Keep it in the service or app-layer dispute lane unless settlement evidence is available
Honest receiver mismatch	Prefer rejection, expiry, or scoped disclosure over broad wallet-history export

Do not promise that every conflict can be solved inside the base protocol. The corpus supports bounded liability, penalty, lock, compensation, and unlock architecture. The exact enforcement loop is target architecture unless a local implementation surface proves otherwise.

Builder API Shape

A future request API should make state and evidence explicit. Good method families would not only say pay(). They would separate request parsing, request display, local acceptance, package preparation, publication, settlement observation, refund handling, quarantine handling, and disclosure export.

The safer developer nouns are:

parse request
validate request scope
classify object family
prepare package
accept locally
reject or quarantine
publish package
observe checkpoint
export scoped evidence

Those nouns keep the handoff staged. They also make it harder for docs to imply that a request itself is final money.

Evidence and Further Reading

Smart Cash sections 4 through 8 define smart cash, client-side FSM objects, public settlement surfaces, proof boundaries, right objects, fee objects, liability objects, and supported object families.
Assets, Rights, And Vouchers Whitepaper section 8 defines payment, acceptance, receiver safety, clean payment versus voucher transfer, refund semantics, and wallet quarantine.
Linked Liability Whitepaper sections 4 through 6 define normal-case execution, fraud detection, liability activation, bonded risk, penalty policy, freeze, slash, quarantine, compensation, and unlock boundaries.
Wallet SDK explains why request flows should stay wallet-local until publication and checkpoint evidence make settlement authoritative.

Z00ZBlockchain