PayNotes
A domain package for governing requests, conditions, evidence, control, and lifecycle around one payment transaction.
What it answers#
A PayNote answers: how should this one payment process be governed, and which provider facts determine its state?
It does not answer whether a bank ledger actually moved money without an authoritative provider Response.
Participants#
The core roles include payer, payee, and guarantor. The guarantor is the provider that controls or authoritatively reports the payment-rail outcome. Depending on the profile, it may be a bank, card processor, wallet, financing provider, marketplace payment service, or another rail-specific institution.
Request and response vocabulary#
The package contains types for requests such as reserve funds, capture, cancellation, reversal, payee assignment, final amount resolution, locks, and child transactions, together with provider Responses for accepted, completed, declined, failed, cancelled, reversed, and other outcomes.
Participant intent and guarantor truth remain different facts.
Rail-neutral lifecycle#
PayNote uses domain vocabulary that can be extended by rail-specific profiles. A conceptual path may include acceptance, initiation, funds secured, completion, cancellation before completion, or reversal after completion.
Production profiles must define exact transition guards, idempotency, currency and amount invariants, partial outcomes, signatures, and provider integration behavior.
Conditional commerce#
An Order or Agreement can request PayNote action when its own conditions are satisfied. Provider Responses can then trigger deterministic consequences in the PayNote and selected related documents.
BEX does not execute payment. The provider does.
Repository status#
The supplied repository contains a large PayNote type family, including stable and .dev content. The package page should always defer to the canonical repository status of each exact type rather than imply one maturity level for the entire catalog.