The standard Blue document for governing one transaction — payer, payee, guarantor; secure / complete / cancel / reverse; deferred recipient selection, final-amount resolution, and control locks.

PayNote Reference

§1. Introduction & Overview

A PayNote is a standard Blue document that attaches to exactly one transaction and governs what should happen with that transaction.

It is not the payment rail itself.

Instead, it is the shared document that describes and controls the payment process around that rail:

who is involved,
what value is expected,
what conditions must be met,
when value should be secured,
when the payment should complete,
when it should be cancelled before completion,
when it should be reversed after completion,
and whether additional transactions should be triggered as a result.

A PayNote may be attached:

at card authorization,
at bank transfer initiation,
at SCA confirmation,
at internal ledger transfer initiation,
at account-to-card payout initiation,
or at another provider-specific payment-initiation point.

By modeling payment logic as a verifiable, event-driven document, a PayNote creates a chain of evidence for the full lifecycle of a transaction. All participants can independently verify what was requested, what was accepted, and what the trusted payment operator actually did.

§2. Core Concepts

2.1 One PayNote attaches to one transaction

This is the key invariant:

A PayNote always governs exactly one transaction.

That transaction may be:

a card authorization,
a bank transfer initiation,
an internal transfer request,
a payout initiation,
or another rail-specific transaction.

If a PayNote later triggers another transaction, that new transaction is independent and may have its own PayNote.

This replaces the older "child PayNote" idea with a cleaner model:

one PayNote → one transaction
triggered transactions are separate
each triggered transaction may have its own PayNote

2.2 The three core participants

Every PayNote has three conceptual core roles:

Payer

The party providing the funds or value.

Payee

The party intended to receive the funds or value.

Guarantor

The trusted entity that controls or executes the underlying transaction.

Examples:

bank
card issuer
payment processor
platform operator
internal ledger operator
wallet provider

The Guarantor is the source of truth for what actually happened on the underlying rail.

2.3 Accepted, then initiated

A PayNote may be accepted by the Guarantor before the full underlying transaction is fully described or completed.

This distinction matters.

Accepted

The Guarantor agrees that this PayNote will govern a particular transaction flow.

Initiated

The underlying rail-specific transaction has actually been started, and the Guarantor now confirms transaction attachment details.

2.4 Transaction details may be unresolved initially

A PayNote can be accepted before all transactional details are known.

That is useful for scenarios like:

a bank approving and securing funds before the final merchant is chosen,
an agent shopping around within a pre-approved budget,
a payment where the payee or recipient target is filled in later.

So a PayNote must support:

payee assignment
transaction details update
and confirmation/rejection of those updates by the Guarantor.

2.5 Canonical lifecycle concepts

At the conceptual level, a PayNote should use the following action vocabulary:

secure the funds
complete the payment
cancel before completion
reverse after completion

These are intentionally more universal than rail-specific words such as:

reserve
capture
void
refund

Different rails can map their own terminology onto these concepts.

Examples

Card

secure the funds = auth / hold approved
complete the payment = capture
cancel before completion = void / auth release
reverse after completion = refund / reversal

Bank transfer

secure the funds = committed / held under provider control (if applicable)
complete the payment = settle / release
cancel before completion = stop before settlement
reverse after completion = return / compensating transfer

Internal ledger

secure the funds = reserve internally
complete the payment = book transfer
cancel before completion = release reservation
reverse after completion = compensating transfer

2.6 Final amount resolution

Many payment flows begin with an expected amount and later need the final amount to be resolved.

Examples:

tip added later
mileage-based delivery payout
restaurant bill updated after order
hotel final charge
partial shipment or partial completion

That is why PayNote should support final amount resolution.

This is better than older "settlement amount" wording, because it focuses on:

the final amount this PayNote should complete for,

not

processor back-office settlement concepts.

2.7 Control locks

A PayNote may need to override or temporarily restrict actions that the Guarantor's rail would otherwise allow.

Examples:

card auth exists, but the system wants to block capture until another condition is met
reversal should be blocked until dispute handling completes
transaction details should no longer be editable after approval

So PayNote should support control-lock operations such as:

completion lock / unlock
reversal lock / unlock
transaction details update lock / unlock

These are powerful because they let the PayNote shape the real payment lifecycle rather than just observe it.

2.8 Triggered transactions

A PayNote may trigger new transactions.

Examples:

a voucher credit after purchase
a split payout after marketplace order
a recurring subscription renewal
a milestone payout
a post-completion bonus payment
a factor advance
an insurance staged payout

Each triggered transaction is:

a new transaction,
independent,
and may have its own PayNote.

§3. Base PayNote Definition

This is the foundational provider-neutral Blue definition.

The base type should stay minimal and general.

Provider-specific packages such as JPM/... or Adyen/... may extend or overwrite parts of the transaction detail model with stronger rail-specific shapes.

YAML

1name: PayNote
2description: >
3  A document attached to exactly one transaction that governs what
4  should happen with that transaction.
5status:
6  type: Text
7  description: >
8    Current lifecycle state of this PayNote.
9    Expected values include:
10    Pending, Accepted, Initiated, Secured, Completed,
11    Cancelled, Reversed, Rejected, Failed.
12  value: Pending
13currency:
14  type: Text
15  description: ISO 4217 currency code.
16amount:
17  description: Amount values associated with this PayNote.
18  expectedTotal:
19    type: Integer
20    description: >
21      The initially expected total amount in minor units.
22  finalResolved:
23    type: Integer
24    description: >
25      The final resolved amount for completion, if known.
26    value: 0
27  finalAmountResolved:
28    type: Boolean
29    description: >
30      Whether the final amount has been explicitly resolved.
31    value: false
32  secured:
33    type: Integer
34    description: >
35      Amount currently secured / under guarantor control.
36    value: 0
37  completed:
38    type: Integer
39    description: >
40      Amount already completed / finalized.
41    value: 0
42  reversed:
43    type: Integer
44    description: >
45      Amount already reversed after completion.
46    value: 0
47transactionDetails:
48  description: >
49    Transaction attachment information confirmed by the Guarantor.
50controls:
51  completionLocked:
52    type: Boolean
53    value: false
54  reversalLocked:
55    type: Boolean
56    value: false
57  transactionDetailsUpdateLocked:
58    type: Boolean
59    value: false
60payNoteInitialStateDescription:
61  summary:
62    type: Text
63    description: >
64      Short explanation of what this PayNote is for.
65  details:
66    type: Text
67    description: >
68      Full explanation of the process, conditions, and special rules.
69      Markdown recommended.
70contracts:
71  payerChannel:
72    type: MyOS Timeline
73  payeeChannel:
74    type: MyOS Timeline
75    # May remain unbound initially if payee/recipient is unresolved.
76  guarantorChannel:
77    type: MyOS Timeline
78
79  # --- Guarantor operations ---
80  acceptPayNote:
81    type: Operation
82    channel: guarantorChannel
83  rejectPayNote:
84    type: Operation
85    channel: guarantorChannel
86  recordTransactionInitiated:
87    type: Operation
88    channel: guarantorChannel
89  recordTransactionInitiationFailed:
90    type: Operation
91    channel: guarantorChannel
92  confirmPayeeAssignment:
93    type: Operation
94    channel: guarantorChannel
95  rejectPayeeAssignment:
96    type: Operation
97    channel: guarantorChannel
98  confirmTransactionDetailsUpdated:
99    type: Operation
100    channel: guarantorChannel
101  rejectTransactionDetailsUpdate:
102    type: Operation
103    channel: guarantorChannel
104  failTransactionDetailsUpdate:
105    type: Operation
106    channel: guarantorChannel
107  secureFunds:
108    type: Operation
109    channel: guarantorChannel
110  declineSecureFunds:
111    type: Operation
112    channel: guarantorChannel
113  failSecureFunds:
114    type: Operation
115    channel: guarantorChannel
116  completePayment:
117    type: Operation
118    channel: guarantorChannel
119  declineCompletePayment:
120    type: Operation
121    channel: guarantorChannel
122  failCompletePayment:
123    type: Operation
124    channel: guarantorChannel
125  cancelBeforeCompletion:
126    type: Operation
127    channel: guarantorChannel
128  declineCancelBeforeCompletion:
129    type: Operation
130    channel: guarantorChannel
131  failCancelBeforeCompletion:
132    type: Operation
133    channel: guarantorChannel
134  reverseAfterCompletion:
135    type: Operation
136    channel: guarantorChannel
137  declineReverseAfterCompletion:
138    type: Operation
139    channel: guarantorChannel
140  failReverseAfterCompletion:
141    type: Operation
142    channel: guarantorChannel
143  resolveFinalAmount:
144    type: Operation
145    channel: guarantorChannel
146    request:
147      type: Integer
148  rejectFinalAmountResolution:
149    type: Operation
150    channel: guarantorChannel
151  lockPaymentCompletion:
152    type: Operation
153    channel: guarantorChannel
154  unlockPaymentCompletion:
155    type: Operation
156    channel: guarantorChannel
157  failPaymentCompletionLockChange:
158    type: Operation
159    channel: guarantorChannel
160  lockPaymentReversal:
161    type: Operation
162    channel: guarantorChannel
163  unlockPaymentReversal:
164    type: Operation
165    channel: guarantorChannel
166  failPaymentReversalLockChange:
167    type: Operation
168    channel: guarantorChannel
169  lockTransactionDetailsUpdate:
170    type: Operation
171    channel: guarantorChannel
172  unlockTransactionDetailsUpdate:
173    type: Operation
174    channel: guarantorChannel
175  failTransactionDetailsUpdateLockChange:
176    type: Operation
177    channel: guarantorChannel

§4. Canonical Participant Requests

These are the standard participant-to-guarantor requests.

Most concrete PayNote documents may expose participant-friendly wrapper operations that emit these requests, but the canonical semantics live here.

4.1 Acceptance

YAML

1name: PayNote Acceptance Requested
2type: Request
3description: >
4  A participant requests that the Guarantor accept this PayNote
5  as governing the referenced transaction.

4.2 Transaction details update

YAML

1name: Transaction Details Update Requested
2type: Request
3description: >
4  A participant requests that the Guarantor update transaction-specific
5  details.

This request is especially useful for:

deferred recipient selection
agent shopping-around flows
target/account selection after initial approval
merchant details filled in after pre-approval

4.3 Secure the funds

YAML

1name: Secure Funds Requested
2type: Request
3description: >
4  A participant requests that the Guarantor secure value for this transaction.
5amount:
6  type: Integer

4.4 Complete the payment

YAML

1name: Complete Payment Requested
2type: Request
3description: >
4  A participant requests that the Guarantor finalize the payment.
5amount:
6  type: Integer

4.5 Cancel before completion

YAML

1name: Cancel Before Completion Requested
2type: Request
3description: >
4  A participant requests that the Guarantor cancel the transaction before completion.
5reason:
6  type: Text

4.6 Reverse after completion

YAML

1name: Reverse After Completion Requested
2type: Request
3description: >
4  A participant requests that the Guarantor reverse value after completion.
5amount:
6  type: Integer
7reason:
8  type: Text

4.7 Final amount resolution

YAML

1name: Final Amount Resolution Requested
2type: Request
3description: >
4  A participant proposes the final amount this PayNote should complete for.
5finalAmount:
6  type: Integer
7reason:
8  type: Text

4.8 Completion lock / unlock

YAML

1name: Payment Completion Lock Requested
2type: Request
3description: >
4  Request that the Guarantor reject subsequent completion attempts
5  for the governed transaction.
6reason:
7  type: Text

YAML

1name: Payment Completion Unlock Requested
2type: Request
3description: >
4  Request that the Guarantor allow subsequent completion attempts
5  for the governed transaction.
6reason:
7  type: Text

4.9 Reversal lock / unlock

YAML

1name: Payment Reversal Lock Requested
2type: Request
3description: >
4  Request that the Guarantor reject subsequent reversal attempts
5  for the governed transaction.
6reason:
7  type: Text

YAML

1name: Payment Reversal Unlock Requested
2type: Request
3description: >
4  Request that the Guarantor allow subsequent reversal attempts
5  for the governed transaction.
6reason:
7  type: Text

4.10 Transaction-details-update lock / unlock

YAML

1name: Transaction Details Update Lock Requested
2type: Request
3description: >
4  Request that the Guarantor reject subsequent transaction-details updates
5  for the governed transaction.
6reason:
7  type: Text

YAML

1name: Transaction Details Update Unlock Requested
2type: Request
3description: >
4  Request that the Guarantor allow subsequent transaction-details updates
5  for the governed transaction.
6reason:
7  type: Text

§5. Canonical Guarantor Responses / Events

These are the authoritative lifecycle responses emitted by the Guarantor.

5.1 Acceptance

YAML

1name: PayNote Accepted
2type: Response
3description: >
4  The Guarantor accepted this PayNote as governing the referenced transaction.

YAML

1name: PayNote Rejected
2type: Response
3description: >
4  The Guarantor rejected this PayNote for the referenced transaction.
5reason:
6  type: Text

5.2 Transaction details update

YAML

1name: Transaction Details Updated
2type: Response
3description: >
4  The Guarantor accepted and recorded updated transaction details.
5payeeRef:
6  type: Text
7recipientTargetRef:
8  type: Text
9merchantReference:
10  type: Text
11displayLabel:
12  type: Text

YAML

1name: Transaction Details Update Rejected
2type: Response
3description: >
4  The Guarantor rejected the proposed transaction details update.
5reason:
6  type: Text

YAML

1name: Transaction Details Update Failed
2type: Response
3description: >
4  The Guarantor attempted to apply the transaction details update,
5  but a technical or provider-level failure occurred.
6reason:
7  type: Text

5.3 Transaction initiation

YAML

1name: Transaction Initiated
2type: Response
3description: >
4  The Guarantor confirms that the underlying transaction was initiated
5  and records how this PayNote was attached to it.
6railType:
7  type: Text
8attachmentPoint:
9  type: Text
10providerReference:
11  type: Text
12initiatedAmount:
13  type: Integer

YAML

1name: Transaction Initiation Failed
2type: Response
3description: >
4  The Guarantor attempted to initiate the transaction, but it failed.
5reason:
6  type: Text

5.4 Securing the funds

YAML

1name: Funds Secured
2type: Response
3description: >
4  The Guarantor confirms that value is now secured / under its control.
5amountSecured:
6  type: Integer

YAML

1name: Funds Securing Declined
2type: Response
3description: >
4  The Guarantor declined the request to secure the funds.
5reason:
6  type: Text

YAML

1name: Funds Securing Failed
2type: Response
3description: >
4  The Guarantor attempted to secure the funds, but a technical or
5  provider-level failure occurred.
6reason:
7  type: Text

5.5 Completing the payment

YAML

1name: Payment Completed
2type: Response
3description: >
4  The Guarantor confirms that the payment was finalized.
5amountCompleted:
6  type: Integer

YAML

1name: Payment Completion Declined
2type: Response
3description: >
4  The Guarantor declined the request to complete the payment.
5reason:
6  type: Text

YAML

1name: Payment Completion Failed
2type: Response
3description: >
4  The Guarantor attempted to complete the payment, but it failed.
5reason:
6  type: Text

5.6 Cancelling before completion

YAML

1name: Payment Cancelled Before Completion
2type: Response
3description: >
4  The Guarantor confirms that the transaction was cancelled before completion.

YAML

1name: Payment Cancellation Declined
2type: Response
3description: >
4  The Guarantor declined the request to cancel before completion.
5reason:
6  type: Text

YAML

1name: Payment Cancellation Failed
2type: Response
3description: >
4  The Guarantor attempted to cancel before completion, but it failed.
5reason:
6  type: Text

5.7 Reversing after completion

YAML

1name: Payment Reversed After Completion
2type: Response
3description: >
4  The Guarantor confirms that value was reversed after completion.
5amountReversed:
6  type: Integer

YAML

1name: Payment Reversal Declined
2type: Response
3description: >
4  The Guarantor declined the request to reverse after completion.
5reason:
6  type: Text

YAML

1name: Payment Reversal Failed
2type: Response
3description: >
4  The Guarantor attempted to reverse after completion, but it failed.
5reason:
6  type: Text

5.8 Final amount resolution

YAML

1name: Final Amount Resolved
2type: Response
3description: >
4  The Guarantor confirms the final amount this PayNote should complete for.
5finalAmount:
6  type: Integer

YAML

1name: Final Amount Resolution Rejected
2type: Response
3description: >
4  The Guarantor rejected the proposed final amount.
5reason:
6  type: Text

5.9 Completion lock / unlock

YAML

1name: Payment Completion Locked
2type: Response
3description: >
4  Payment completion was locked. Subsequent completion attempts
5  must be rejected until explicitly unlocked.
6lockedAt:
7  type: Common/Timestamp

YAML

1name: Payment Completion Unlocked
2type: Response
3description: >
4  Payment completion was unlocked. Subsequent completion attempts
5  may now be processed again.
6unlockedAt:
7  type: Common/Timestamp

YAML

1name: Payment Completion Lock Change Failed
2type: Response
3description: >
4  The requested completion-lock change failed.
5reason:
6  type: Text

5.10 Reversal lock / unlock

YAML

1name: Payment Reversal Locked
2type: Response
3description: >
4  Payment reversal was locked. Subsequent reversal attempts
5  must be rejected until explicitly unlocked.
6lockedAt:
7  type: Common/Timestamp

YAML

1name: Payment Reversal Unlocked
2type: Response
3description: >
4  Payment reversal was unlocked. Subsequent reversal attempts
5  may now be processed again.
6unlockedAt:
7  type: Common/Timestamp

YAML

1name: Payment Reversal Lock Change Failed
2type: Response
3description: >
4  The requested reversal-lock change failed.
5reason:
6  type: Text

5.11 Transaction-details-update lock / unlock

YAML

1name: Transaction Details Update Locked
2type: Response
3description: >
4  Transaction-details updates were locked. Subsequent details changes
5  must be rejected until explicitly unlocked.
6lockedAt:
7  type: Common/Timestamp

YAML

1name: Transaction Details Update Unlocked
2type: Response
3description: >
4  Transaction-details updates were unlocked. Subsequent details changes
5  may now be processed again.
6unlockedAt:
7  type: Common/Timestamp

YAML

1name: Transaction Details Update Lock Change Failed
2type: Response
3description: >
4  The requested transaction-details-update lock change failed.
5reason:
6  type: Text

§6. Why deferred recipient selection is worth supporting

Yes — this is a very good scenario and worth making first-class.

Example use case

Alice gets a PayNote approved by her bank
funds may already be secured
but the final recipient is not fixed yet
Alice adds her agent
the agent shops around
later the agent proposes recipient details
the Guarantor confirms or rejects the update
then the payment can complete

This is useful for:

shopping agents
marketplace sourcing
travel / booking search
dynamic merchant selection
pre-approved spend with later target resolution

This is exactly why PayNote needs:

payee assignment
transaction details update
and optionally details-update locks

Without these, agentic pre-approval flows become awkward.

§7. Use Cases & Examples

Example 1: Simple direct bank transfer

Scenario

Alice wants to send Bob $250. The transfer should complete immediately once initiated.

YAML

1name: Payment for Invoice Q3-SERVICES
2type: PayNote
3currency: USD
4amount:
5  expectedTotal: 25000
6payNoteInitialStateDescription:
7  summary: |
8    Direct payment of **$250.00 USD** from Alice to Bob.
9  details: |
10    This PayNote governs a simple direct payment.
11    The Guarantor initiates and completes it immediately if possible.
12contracts:
13  bootstrap:
14    type: Sequential Workflow
15    event:
16      type: Document Processing Initiated
17    steps:
18      - name: RequestCompletion
19        type: Trigger Event
20        event:
21          type: Complete Payment Requested
22          amount: ${document('/amount/expectedTotal')}
23  payerChannel:
24    type: MyOS Timeline
25  payeeChannel:
26    type: MyOS Timeline
27  guarantorChannel:
28    type: MyOS Timeline

Typical outcome

PayNote Accepted
Transaction Initiated
Payment Completed

Example 2: Delivery-protected card payment

Scenario

A customer pays a merchant €120. The card is authorized now, but the payment should complete only after DHL confirms delivery.

YAML

1name: Delivery-Protected Payment #SH-481516
2type: PayNote
3currency: EUR
4amount:
5  expectedTotal: 12000
6contracts:
7  payerChannel:
8    type: MyOS Timeline
9  payeeChannel:
10    type: MyOS Timeline
11  guarantorChannel:
12    type: MyOS Timeline
13  shipmentCompanyChannel:
14    type: MyOS Timeline
15  bootstrap:
16    type: Sequential Workflow
17    event:
18      type: Document Processing Initiated
19    steps:
20      - name: RequestSecureFunds
21        type: Trigger Event
22        event:
23          type: Secure Funds Requested
24          amount: ${document('/amount/expectedTotal')}
25  shipmentConfirmed:
26    type: Operation
27    channel: shipmentCompanyChannel
28  shipmentConfirmedImpl:
29    type: Sequential Workflow Operation
30    operation: shipmentConfirmed
31    steps:
32      - name: RequestCompletion
33        type: Trigger Event
34        event:
35          type: Complete Payment Requested
36          amount: ${document('/amount/finalResolved') || document('/amount/expectedTotal')}

Typical outcome

PayNote Accepted
Transaction Initiated
Funds Secured
DHL confirms shipment
Complete Payment Requested
Payment Completed

If needed, the system can also lock completion before delivery:

Payment Completion Lock Requested
Payment Completion Locked
later unlock and complete

Example 3: Deferred recipient selection for an agent

Scenario

Alice secures $1,000 with her bank but does not yet know which merchant will be used. Her agent shops around and later supplies the recipient details.

YAML

1name: Shopping Budget with Deferred Recipient
2type: PayNote
3currency: USD
4amount:
5  expectedTotal: 100000
6contracts:
7  payerChannel:
8    type: MyOS Timeline
9  guarantorChannel:
10    type: MyOS Timeline
11  agentChannel:
12    type: MyOS Timeline
13  proposeRecipient:
14    type: Operation
15    channel: agentChannel
16    request:
17      type: Text
18  proposeRecipientImpl:
19    type: Sequential Workflow Operation
20    operation: proposeRecipient
21    steps:
22      - name: RequestDetailsUpdate
23        type: Trigger Event
24        event:
25          type: Transaction Details Update Requested
26          recipientTargetRef: ${event.request}

Typical outcome

PayNote Accepted
Transaction Initiated
Funds Secured
agent finds a merchant and proposes target details
Transaction Details Updated
Complete Payment Requested
Payment Completed

This is a very strong scenario for safe agentic shopping.

Example 4: Agent budget with triggered independent transactions

Scenario

Alice secures $1,000 for travel. The PayNote governs the top-level budget transaction. As travel choices are made, new transactions are triggered independently.

Snippet

1Top-level transaction: card hold / account hold ($1,000)
2└── PayNote A: "Agent may trigger approved travel transactions within this budget"
3    ├── Transaction B: Flight auth ($400)
4    │   └── PayNote B: "Complete immediately if ticket issued"
5    ├── Transaction C: Hotel auth ($500)
6    │   └── PayNote C: "Complete at check-in, cancel if trip cancelled"
7    └── Transaction D: Restaurant auth ($60)
8        └── Optional PayNote D

Key point

There are no child PayNotes here.

There is:

one top-level transaction + PayNote,
and then multiple separate triggered transactions.

Example 5: Final amount resolution before completion

Scenario

A courier flow starts with an estimate, but the final amount depends on actual mileage.

YAML

1name: Mileage-Based Courier Payment
2type: PayNote
3currency: USD
4amount:
5  expectedTotal: 1500
6  finalResolved: 0
7  finalAmountResolved: false

Typical outcome

PayNote Accepted
Transaction Initiated
Funds Secured
Final Amount Resolution Requested
Final Amount Resolved
Complete Payment Requested
Payment Completed

§8. What this version changes from the old model

This version makes the following improvements:

Removed

Child PayNotes
"Settlement Amount" as the main concept

Added

Accepted as the correct early lifecycle state
transaction details update
payee assignment
completion / reversal / details-update locks
final amount resolution
a cleaner, more rail-neutral action vocabulary

Preserved

Payer / Payee / Guarantor as the core participant model
event-driven lifecycle
authoritative Guarantor responses
strong audit / chain-of-evidence semantics

§9. Summary

A PayNote is a document attached to one transaction that governs what should happen with that transaction.

Its canonical concepts are:

accept the PayNote
initiate the transaction
secure the funds
complete the payment
cancel before completion
reverse after completion
resolve the final amount
update transaction details when needed
lock or unlock sensitive transitions when needed

Each triggered transaction is independent and may have its own PayNote.

That makes PayNote:

simpler than the old "child" model,
more general than card-only language,
and much better suited to modern agentic, multi-party, and cross-rail payment flows.

PayNote reference

PayNote Reference

§1. Introduction & Overview

§2. Core Concepts

2.1 One PayNote attaches to one transaction

2.2 The three core participants

Payer

Payee

Guarantor

2.3 Accepted, then initiated

Accepted

Initiated

2.4 Transaction details may be unresolved initially

2.5 Canonical lifecycle concepts

Examples

2.6 Final amount resolution

2.7 Control locks

2.8 Triggered transactions

§3. Base PayNote Definition

§4. Canonical Participant Requests

4.1 Acceptance

4.2 Transaction details update

4.3 Secure the funds

4.4 Complete the payment

4.5 Cancel before completion

4.6 Reverse after completion

4.7 Final amount resolution

4.8 Completion lock / unlock

4.9 Reversal lock / unlock

4.10 Transaction-details-update lock / unlock

§5. Canonical Guarantor Responses / Events

5.1 Acceptance

5.2 Transaction details update

5.3 Transaction initiation

5.4 Securing the funds

5.5 Completing the payment

5.6 Cancelling before completion

5.7 Reversing after completion

5.8 Final amount resolution

5.9 Completion lock / unlock

5.10 Reversal lock / unlock

5.11 Transaction-details-update lock / unlock

§6. Why deferred recipient selection is worth supporting

Example use case

§7. Use Cases & Examples

Example 1: Simple direct bank transfer

Example 2: Delivery-protected card payment

Example 3: Deferred recipient selection for an agent

Example 4: Agent budget with triggered independent transactions

Example 5: Final amount resolution before completion

§8. What this version changes from the old model

Removed

Added

Preserved

§9. Summary