How do I bind an AI agent's payment receipt to what triggered it, the policy that allowed it, the payment details and its idempotency key, and reconcile against the provider before replaying a run?

What should I check, step by step?

1. Give each payment step a stable receipt id and idempotency key, created when the agent commits to paying and saved before the first call to the provider.

2. Record the trigger: task id, step id, the message or event that caused the payment, and a hash of the inputs the agent used (invoice, quote, Payment Required body).
3. Record the decision: policy id and version, the allow or deny and its reason, the approval id, approver and expiry if one was needed, and the action hash the approval covered.
4. Record the payment: provider, provider payment id (PaymentIntent, charge, transaction hash), amount in minor units, currency, payee, status and the time of the last status you saw.
5. Hash the canonical receipt (RFC 8785 JSON or a fixed field order) and chain or sign it, so a later edit to any field shows.
6. Write receipt_id and the idempotency key into the payment's own metadata or reference field, so you can find the payment from the receipt and the receipt from the payment.
7. Before replaying or resuming, run a reconcile pass over every payment step: fetch the provider record, compare it with the receipt, and label each step matched, missing, mismatched or unknown.
8. Replay matched steps from the receipt, retry missing steps only with the same idempotency key and a still-valid approval, and stop on mismatched or unknown.

Why does an agent payment receipt need the trigger, policy, payment and idempotency key?

Trigger without payment details tells you why the agent wanted to pay, but not what actually left the account.

• Payment details without the policy decision tell you what was paid, but not which rule or which person allowed it, which is what a reviewer or auditor asks first.
• The idempotency key is what joins your record to the provider's. Stripe returns the saved result for a repeat request with the same key and errors if parameters change under it; the IETF Idempotency-Key draft says a key must not be reused with a different payload. Without the key in the receipt you can't prove a replayed call was the same payment.
• With all four, any one of them can be checked against the others: the amount against the approved action hash, the payment against the key, the trigger against the recorded inputs.

How do I reconcile agent payments before replaying a run?

Durable-execution tools replay recorded results so finished work isn't redone: Temporal replays a workflow from its event history, and LangGraph's durable execution saves task results so they're reused when a run resumes. A payment that happened outside that record, or whose result was lost in a crash, needs an explicit check.

• Look payments up by id or by your own reference. Stripe lets you search Charges and PaymentIntents by metadata, but its docs say not to use search for read-after-write flows because new data can take up to about a minute to appear; for a payment just made, retrieve it by id or use the list APIs.
• Compare status, amount, currency and payee with the receipt. Treat a timeout or an unknown status as unknown, not failed, and don't retry until you've found out what happened.
• Write the reconcile result into the run record (step, receipt id, provider status, verdict, checked_at), so the replay itself leaves evidence of what it found.

What should happen to each payment step after reconciliation?

Matched: the provider shows the payment as the receipt describes. Replay returns the recorded result; no new call to the provider.

• Missing: no payment exists under that key or reference. Retry with the same idempotency key, and only if the approval hasn't expired and the action hash still matches.
• Mismatched: the provider shows a different amount, currency, payee or status (for example refunded). Stop the replay and send it to a person; something changed outside the run.
• Unknown: the provider couldn't be reached or the status is still pending. Wait and check again; don't pay.

What are the common failure modes?

The idempotency key is generated inside the HTTP call, so the replay sends a new key and the provider happily charges again.

• Stripe idempotency keys can be pruned after 24 hours, so a replay days later can't rely on the key alone; it needs the reconcile lookup by payment id or metadata.
• The receipt stores the amount the agent intended, not the amount the provider confirmed, so currency conversion or fees make every check fail or, worse, pass silently.
• The reconcile step uses search immediately after paying and finds nothing, then retries.
• Receipts are written to the agent's own log folder, where a later step can edit or delete them.