An email receipt is not proof of payment: reconciling AI agent purchases

An AI agent should use a receipt email to find and explain a purchase, then verify its payment state through the authenticated payment system. A receipt alone should never trigger another payment, release an order or turn an uncertain transfer into a success report.

Keep three records separate: what the user authorized, what the payment system reports, and what the merchant emailed. Link them with stable identifiers. When they disagree, preserve the evidence and ask for review instead of letting the model guess.

A receipt, an invoice and a payment result answer different questions

An invoice asks for payment. An order confirmation says the merchant recorded an order. A receipt describes a payment, but can arrive late, be forwarded twice, refer to a different order or be forged. A refund notification describes another event that also needs verification.

The payment provider's authenticated record is the place to check the state of the specific transaction. Its vocabulary matters: authorized, processing, captured, succeeded, refunded and disputed are not interchangeable. A successful payment does not guarantee that a product was delivered or that a later refund cannot occur.

For a concrete example, Stripe's payment status documentation distinguishes processing, success and failure, and describes server-side event handling. That is a Stripe example, not evidence that every wallet uses PaymentIntent states or that Mermail has a Stripe reconciliation integration.

Start with the authorized order

Before matching an email, your application should already know the purchase it intended to make. Store the merchant account, internal order ID, approved item or service, expected amount and currency, and the payment request ID returned by the actual payment system. For an onchain payment, include the intended asset and network as well.

Keep the user's authorization separate from the email extraction. An invoice cannot expand a spend cap, change a recipient or authorize a new purchase. A message that says “the first payment failed; send again here” is a claim to investigate, not a new instruction.

Use an agent-owned inbox for the merchant account's confirmations and receipts. Keep unrelated personal mail out of the matching process. Our agent signup and verification guide explains how to assign the mailbox to the service account before its messages arrive.

Match identifiers before amounts

Extract candidate fields from the receipt: merchant order reference, receipt number, amount, currency and issue date. Retain a pointer to the original message so a reviewer can inspect it. Do not store payment secrets or signing material in this record.

Prefer a merchant order reference that your application already recorded. A sender display name, subject line, amount or timestamp alone is not a reliable match: two purchases can cost the same amount, and forwarded messages can resemble originals. Email authentication can help assess a sender, but it does not prove settlement.

If the merchant does not expose a reference you can independently correlate, mark the candidate as unmatched. Do not invent a transaction ID or choose the nearest-looking payment. A person may need to resolve the association in the authenticated merchant account.

Keep payment state and receipt state independent

A useful application record can have a payment state such as unknown, pending, confirmed or failed, alongside a receipt state such as missing, matched, duplicate or needs review. These are illustrative application labels, not Mermail API fields. Map them explicitly to the provider's documented states.

Consider a synthetic purchase for order DEMO-104, expected amount USD 12.00. The payment system confirms its known request, but no receipt arrives. Record “payment confirmed; receipt missing.” Do not pay again to produce an email. If two copies of the matching receipt arrive later, attach them to the existing order without creating a second purchase.

Now change the example: the email says USD 120.00, or the transaction lookup times out. The first case needs a mismatch review; the second remains unknown. Neither becomes a confirmed match just because the message contains the word “paid.” These examples are design walkthroughs; no live payment or email integration was executed for this article.

Handle duplicates and delayed events without repeating the purchase

Make receipt processing safe to repeat. Your application can keep a processed-message identifier and a separate unique business key based on the merchant account and receipt or order reference. The first prevents processing the same delivery twice; the second helps detect a re-sent receipt with a new message identifier. Do not use amount alone as the key.

When consuming payment webhooks, follow the provider's authentication, duplicate handling and ordering guidance. Stripe's webhook documentation covers signature verification, duplicate events and delivery ordering. Re-read the relevant transaction when your integration needs its current state; do not assume the most recently delivered event describes the newest state.

Deduplicating receipt processing does not make a payment submission idempotent. Those are different operations with different guarantees.

What this means in Mermail

Mermail's Agent Wallet overview documents keeping an agent inbox, verification messages and payment context in one workflow. Wallet access depends on delegated permissions and the live capabilities available to the account. This article describes application-level reconciliation; it does not claim Mermail automatically matches receipts or maintains your accounting ledger.

The wallet recovery reference is especially important for uncertain submissions: do not retry automatically. Verify the known request and destination before further action. Pending and SUBMISSION_UNKNOWN are unresolved, and an unavailable portfolio read does not mean a zero balance. A receipt email cannot override those states.

Keep approval policy explicit. A valid standing grant may allow an eligible wallet action without a fresh click; do not promise that every payment gets a new approval prompt. Reading a receipt is not permission to initiate another payment.

Test the boundaries before connecting real money

Use synthetic fixtures for a matching receipt, duplicate delivery, reissued receipt with a new message ID, wrong currency, wrong amount, missing order reference, pending transaction, lookup outage and a refund notice. Require each scenario to preserve the original authorization and avoid a new payment submission. Test actual provider adapters separately before using them in production.

The agent email testing guide provides a starting point for separating fixtures from live execution. If the application cannot explain why a receipt belongs to a particular purchase, route it to review.

Create a Mermail account to give the agent a separate inbox for its service accounts and receipts. Add delegated payment access only when the task needs it, and keep the transaction result as the source of payment status.