The Payment Lifecycle Is Longer Than the Transfer
For agentic commerce and agent-to-agent finance, the useful object to follow is not the coin or token moving between addresses. It is the payment obligation: a request formed for a particular service, under a principal's authority, and expected to produce a particular result. This chapter traces that obligation through discovery, authorization, execution, and accounting so the reader can locate where intent is preserved, where it can be lost, and why a valid settlement does not close the case.
A conventional checkout compresses much of this into a single visible moment. A person selects a merchant, reviews an amount, authenticates, and receives a confirmation. The infrastructure can treat the account and the payment details as the main facts because the person is present to resolve ambiguity and judge whether the service was delivered. An agent-mediated workflow distributes those judgments across software and time. The agent may find the counterparty, negotiate terms, call several tools, retry a failed operation, and report completion without a person watching each transition.
Four stages of one payment obligation
The four-stage lifecycle used in research on blockchain agent payments is a compact way to preserve those distinctions. It is not a claim that every system implements identical components. It is a diagnostic model: at each stage, ask what new fact has been established, what information must persist, and what can go wrong before the obligation moves forward.
1. Discovery forms a payable operation
Discovery is more than finding an endpoint that answers. It identifies a service or counterparty that could satisfy the request and turns that match into a structured payment intent. The structure may include the requested resource, price or payment terms, recipient, asset, and a stable request or session reference. Those details give later stages something persistent to authorize and reconcile.
This is where the obligation gets its referent. If an agent is looking for a data service, “a data service” is not enough. The workflow needs to know which provider, which capability, which terms, and which interaction the eventual payment belongs to. If the agent is buying a product, a catalogue label may need to be tied to a specific item, seller, or evidence record. Without that connection, a payment can be correctly formatted while pointing at the wrong economic object.
Discovery also carries information about trust and admissibility. A service description may state what an agent can do; a registry may add identity or delegation information; past behavior may provide a reputation signal. None of those signals is automatically conclusive. A reachable endpoint can be counterfeit, a capability description can be misleading, and a record of past transactions can be gamed. Discovery therefore begins the trust problem; it does not solve it.
2. Authorization decides whether the intent may be executed
Authorization is the admissibility gate. It asks whether an authenticated request, tied to a principal and an intent, fits the rules governing delegated spending. Those rules may impose a budget, restrict assets or recipients, limit callable operations, require approval above a threshold, or depend on time and prior state.
This stage is different from identity. Identity asks who or what is acting and who stands behind it. Authorization asks whether this actor may perform this particular action under the relevant mandate. It is also different from execution. An authorization decision permits a possible state transition; it does not mean that the transaction has been submitted, included, or fulfilled.
The distinction is important because a transaction can be authorized in a narrow technical sense and still be wrong in a broader behavioral sense. A series of small payments may remain under an individual allowance while exceeding the principal's practical budget. A permitted recipient may be inappropriate for the current purpose. A valid session may outlive the circumstances that made the delegation sensible. Authorization is a gate over an action; it is not, by itself, a continuing interpretation of the principal's goals.
3. Execution turns permission into events and states
Execution is where the authorized intention becomes a concrete interaction. The agent or a facilitator may construct a payment, obtain fees, submit it to a rail, invoke the service, receive an output, and respond to failures or retries. On a blockchain, inclusion and confirmation change what the network recognizes as settled. In an off-chain design, signed updates or an intermediate state may allow a workflow to continue before global settlement.
Several states that look similar to a user are operationally different. A transaction can be constructed but not submitted. It can be submitted but not included. It can be included but not final under the rail's required confirmation rule. It can be final while the service is missing, partial, or incorrect. A relay, bundler, paymaster, or facilitator can fail even when the underlying chain is operating normally. A retry can be necessary for liveness, but it can also duplicate an action if the workflow does not carry a stable request reference and idempotent semantics.
The lifecycle therefore needs explicit transition triggers. What moves an obligation from “authorized” to “executing”? What counts as a failed attempt rather than a completed payment? Which state is authoritative when an off-chain update and an on-chain record arrive at different times? The answers vary by design, but leaving them implicit forces the agent, service, and accounting system to infer different versions of reality.
4. Accounting connects the event to its meaning
Accounting is not only a ledger balance. It maintains the records that connect the payment action to its originating intent and observed outcome. That connection supports reconciliation: checking that the amount, recipient, asset, and transaction correspond to the authorized request. It also supports operational monitoring, dispute resolution, and responsibility attribution.
A useful accounting record may need to preserve more than the final transaction identifier. It may need the principal and agent identity, the request or workflow context, the policy decision, the service response, the timing of retries, and the evidence used to decide that the task was complete. The purpose is not to expose every internal model state. It is to preserve enough causal structure to answer why the payment occurred, what it bought, and which party or component can respond when the result is contested.
These four stages are not four independent boxes. The same intent context must persist as the obligation moves forward. A counterparty chosen during discovery must remain identifiable at authorization and settlement. A budget decision must be linked to the payment that consumes it. An execution result must be available to accounting rather than left in a separate, unverifiable channel.
The diagram shows why “payment completed” is only one transition. Discovery creates the referent; authorization creates an admissible scope; execution creates service and settlement events; accounting decides whether those events can be connected and reviewed. The intent context must travel through all of them. If it disappears at a boundary, later systems can still process their local inputs while losing the meaning of the original obligation.
How a valid mistake travels through the system
The hardest failures are not always rejected transactions. They are transactions that pass every local check because the wrong thing was bound at the beginning, the authority changed in meaning over time, or the system defined completion too narrowly.
Suppose an agent receives a request to obtain a particular service. During discovery, it encounters a convincing but counterfeit endpoint. The endpoint returns a valid-looking capability description and supplies payment terms. The agent forms an intent for that counterparty. Authorization checks the amount, asset, and spending scope; everything appears admissible because the authorization layer is evaluating the intent it received, not independently proving that discovery identified the intended provider. Execution then submits the payment, and the settlement rail records it. Accounting can faithfully preserve the transaction and the endpoint's response. The workflow is internally consistent and still wrong.
This is an upstream misbinding. No later stage can repair it simply by being more accurate about its own task. A stronger identity and discovery layer is required before authorization can mean what the principal expects. The lesson is structural: correctness does not flow backward. A perfect settlement of a misidentified obligation is a perfectly settled mistake.
A second path begins with a correctly identified counterparty but an authority that is too narrow in one dimension and too broad in another. Imagine a standing permission that allows a service agent to make payments under a per-transaction cap. The agent is manipulated, miscalibrated, or simply persistent. It fragments a larger economic action into many permitted payments, repeats a request after an ambiguous response, or continues after the principal's circumstances have changed. Each transaction may satisfy the local rule. The sequence can still violate the purpose for which authority was granted.
Here the failure is not necessarily stolen credentials. It is a gap between formal permission and behavioral alignment. The authorization stage needs context, history, revocation, and escalation signals if it is to govern an evolving workflow. Otherwise, the system treats a standing rule as a permanent expression of consent when it may only have been a conditional convenience.
A third path begins when payment is treated as the completion signal. In an inclusion-gated design, the service may become available once a payment transaction is confirmed. In an off-chain design, an intermediate update may be enough to continue. In either case, financial finality can arrive while the service is absent, partial, or not fit for the user's need. The system has a payment-completion event but no shared definition of economic completion.
That distinction changes the dispute. If the only evidence is a transaction record, the payer can prove that value moved and the provider can prove that the payment was received. Neither record necessarily proves that the promised task was performed. A later refund process must then reconstruct the service outcome from logs, messages, or testimony that was not part of the settlement condition. The result is a post hoc correlation rather than a built-in connection between service and payment.
Execution also introduces timing and finality problems. Public-chain state may be delayed or probabilistic. Off-chain state may be fast but locally visible rather than globally authoritative. A facilitator may submit a transaction on behalf of an agent, making fee handling easier while adding another operational dependency. If one component interprets “success” as submission and another interprets it as final inclusion, the same obligation can advance twice or remain stuck in contradictory states.
Accounting is where these differences become visible, but it is often too late to fix them. A transaction hash can prove a state change; an execution log can show a tool call; a service receipt can assert delivery. The central question is whether those artifacts refer to the same intent, principal, agent, counterparty, and workflow. If each system keeps its own identifier or omits its transition reason, a reviewer must guess how the pieces fit together.
The lifecycle perspective leads to a restrained conclusion. Each stage has a proper job, and none should claim another stage's evidence. Discovery can establish a candidate referent, not service quality. Authorization can establish admissibility, not completion. Execution can establish a network or service event, not necessarily usefulness. Accounting can preserve and reconcile evidence, but cannot manufacture evidence that earlier stages never collected.
For that reason, safe agentic spending is a consistency problem across transitions. The intent must remain recognizable when a service is selected, authority is checked, a transaction is retried, a rail reaches finality, and an outcome is disputed. The next infrastructure question follows directly: how can the system make the counterparty and the principal's purpose durable before an agent receives permission to act, without turning that permission into an unlimited blank cheque?