Every prior module solved one slice of the problem. This module stitches the slices into a single path that a real payment travels, from the moment a user asks an agent to buy something to the moment the audit log closes. The point is not a diagram for its own sake. The point is a concrete sequence you can hold against your own design and find the gap.
A money-moving agent fails at the seams between controls, not inside any one control. So we walk the seams in order, name what crosses each one, and show where a request gets stopped if something is wrong.
The flow, end to end
We use one worked example throughout: a procurement agent at a mid-size company is told to reorder a specific list of office supplies, up to a $750 ceiling, from an approved vendor. Here is the full path.
1. Identity is established before anything moves
The agent does not act as the user. It acts as a distinct workload principal with its own identity, issued by your IdP and bound to the human who delegated the task. This is the immaturity we opened the course with: most stacks still let agents inherit a human's session token, which collapses accountability.
In our example, the agent authenticates as agent://procurement-bot/instance-4471, and the human approver is recorded as a separate principal. Two identities, never one.
2. Intent is separated from authentication
A valid token proves the agent is who it says it is. It says nothing about what the agent is allowed to do right now. Module 2 drew that line, and the architecture enforces it by refusing to treat a successful login as permission to spend.
The authorization question (reorder these SKUs, under $750, from this vendor) is answered by mandates, not by the token.
3. Credentials are scoped and short-lived
The agent receives a credential narrowed to this task and expiring in minutes, not a standing key. If the credential leaks, the blast radius is one vendor, one ceiling, one short window. We covered the mechanics in Module 3; here it is the second gate the request passes.
4. A mandate carries the user's actual instruction
This is where the Agent Payments Protocol (AP2), announced by Google in September 2025 with more than 60 organizations including Mastercard, Adyen, American Express, PayPal, and Worldpay, gives us a concrete shape. AP2 expresses authorization as W3C Verifiable Credentials, cryptographically signed and tamper-resistant.
AP2 defines three mandates, and our flow uses all three:
- An Intent Mandate captures the user's high-level rule: reorder the standing list, under $750, from the approved vendor. It governs the human-not-present case where the agent acts later without the user watching.
- A Cart Mandate captures explicit approval of a specific cart, the exact items and final price, for the human-present case. The merchant signs the cart contents; the user signs over that, producing a co-signed credential.
- A Payment Mandate is the minimal credential derived from the cart and appended to the payment authorization. It signals to the network and issuer that an agent was involved, and whether a human was present, without exposing the full cart to every party.
The mandate is the answer to "who really asked for this," and it travels with the transaction rather than living in a log somewhere.
5. Every tool call passes through the gateway
The agent never holds a vendor API key or talks to a payment rail directly. It talks to a tool gateway that brokers each call, checks the mandate and credential against policy, and enforces least agency. Module 6 built this; in the architecture it is the chokepoint every other control routes through.
When our procurement agent tries to call place_order, the gateway evaluates policy as code: is the vendor approved, is the total under the mandated ceiling, has the credential expired, does the Cart Mandate match the items being purchased. A $812 cart fails here, silently and before any money moves.
6. Humans review at the right gate, not every gate
Human-in-the-loop is a tiered decision, not a blanket approval prompt that trains people to click yes. Module 7 framed the gates: advisory, validating, blocking, escalating. The architecture wires the spend ceiling and the vendor list to those tiers.
Under $750 to an approved vendor with a matching mandate runs unattended. A new vendor, or a cart that touches the ceiling, escalates to the named approver, whose decision is itself a signed event. The human is spent where judgment actually changes the outcome.
7. The audit log is tamper-evident and closes the loop
Every step above writes to an append-only, tamper-evident log: the agent identity, the mandate IDs, the gateway policy decision, the human approval, the final Payment Mandate. Module 8 covered the construction. Here it is the record that lets you answer, weeks later, exactly who authorized what and on what evidence.
Because the mandates are verifiable credentials, the log does not just say "approved." It holds the signed artifacts, so a dispute is settled by re-verifying signatures, not by trusting your own database.
Where this gets stress-tested
Module 9's red-teaming is not a separate phase you run once. It is the practice that keeps the architecture honest, because the promptware kill chain from Module 5 targets exactly these seams. A prompt injection that convinces the agent to "use the emergency vendor" is stopped at the gateway, not the model, because the approved-vendor check lives in policy the agent cannot edit.
Run the adversarial cases against the assembled flow, not the components in isolation. The failure you are looking for is the one where each control passed its own test and the request still slipped between two of them.
The takeaway
A governed agent payment is not one feature. It is a chain in which a distinct agent identity, a scoped short-lived credential, a signed mandate, a policy-enforcing gateway, a tiered human gate, and a tamper-evident log each refuse the request unless the one before it is sound.
Hold your own design against this sequence. If you cannot point to where each gate sits and what stops the request when it fails, you do not yet have a governed flow. You have an agent with a payment method.