Mastercard just launched Agent Pay for Machines. Here's the execution gap they didn't mention.

Mastercard launched Agent Pay for Machines with Stripe, Coinbase, Adyen, and 30 other partners, covering agent identity, spend limits, and payment settlement. However, it does not address execution safety when an agent crashes after a payment fires, leading to duplicate charges. A developer proposes an exactly-once execution guard using deterministic request IDs and durable storage to prevent side effects from firing twice.

On June 10, Mastercard launched Agent Pay for Machines with Stripe, Coinbase, Adyen, and 30 other partners. It covers agent identity, spend limits, and payment settlement. It doesn't cover what happens when the agent crashes after the payment fires. Here's the failure mode: create payment intent create payment intent againIdentity verified. Spend limit not exceeded. Two charges. One customer. This happened in production with LangChain — $47K in duplicate transactions. LangGraph — $4.2K over a weekend. My own live trading session — six duplicate executions blocked, $3,653 total exposure. The idempotentHint annotation in MCP tells clients a tool can be safely retried. It doesn't prevent the side effect from firing twice. It's advisory, not a guard. Before any irreversible action, derive a deterministic request id from the action's inputs and claim it in durable storage outside the execution context. If the agent crashes and retries, the guard returns the cached result without re-executing. python import requests def safe payment agent id: str, customer id: str, amount: int : scope = f"payment:stripe:{customer id}:{amount}" claim = requests.post "https://safeagent-production.up.railway.app/claim/test", json={ "agent id": agent id, "action type": "payment.send", "scope": scope } .json if claim "status" == "SKIP": return claim "existing" result = stripe.PaymentIntent.create amount=amount, currency="usd", customer=customer id requests.post f"https://safeagent-production.up.railway.app/settle/{claim 'request id' }" return result Same pattern works with LangChain tools: python from langchain.tools import tool import requests @tool def create payment customer id: str, amount: int - str: """Create a payment. Exactly-once guarded.""" claim = requests.post "https://safeagent-production.up.railway.app/claim/test", json={ "agent id": "langchain-agent", "action type": "payment.send", "scope": f"stripe:{customer id}:{amount}" } .json if claim "status" == "SKIP": return f"Already processed: {claim 'existing' }" result = stripe.PaymentIntent.create amount=amount, currency="usd", customer=customer id requests.post f"https://safeagent-production.up.railway.app/settle/{claim 'request id' }" return result.id Mastercard AP4M validates the market. Agents are going to make payments at scale. The identity and spend limit problems are solved. The execution safety problem is not. This week, four independent implementations shipped byte-verifiable conformance fixtures for the complete execution safety stack: 11/11 cross-implementation binding digests byte-identical. 33/33 gateway assertions pass. 30/30 verifier assertions pass. All independently verifiable — no runtime trust required. evidai said it best in the A2A RFC thread: "nonce + exactly-once guard together give replay safety; a standalone normative nonce field without the guard would not." pip install safeagent-exec-guard Or test the hosted endpoint directly — no auth required: curl -X POST https://safeagent-production.up.railway.app/claim/test \ -H "Content-Type: application/json" \ -d '{"agent id":"my-agent","action type":"payment.send","scope":"test-123"}' First call: {"status": "PROCEED"} Same call again: {"status": "SKIP"} The conformance fixtures, verify scripts, and cross-impl check are at github.com/azender1/SafeAgent https://github.com/azender1/SafeAgent . If your agent touches payments, emails, webhooks, or trades — and it retries on failure — this is the gap in your stack.