Learn A2A - Ecosystem: A2A x402 & Commerce

#Introduction

Episode 18 took you to the performance level: tasks in the thousands per second with pooling, caching, load balancing, and gRPC. Now the question changes — no longer "how do we serve faster", but "should this agent be served at all". In the real world, services cost money, and agents that do work deserve to be paid.

Episode 19 introduces the commerce layer of the A2A ecosystem. We'll discuss the x402 extension that lets agents request payment via the HTTP 402 status code, the mandate and approval concepts that keep transaction authorization in check, then interop with UCP and AP2 as the big map of agentic commerce — including the trust rails from Visa and Mastercard that underpin trust behind the scenes.

#HTTP 402: The Payment Status Code

Most HTTP codes are familiar: 200 success, 404 not found, 500 server error. There's one code that has sat idle since 1998: 402 Payment Required. It never had a standard meaning — until the x402 ecosystem gave it one: "this work can be done, but you have to pay first."

When an agent client sends a task to a paid remote agent, the remote agent doesn't simply refuse. It replies with status 402 and includes a payment request — a price description, denomination, receiver, and instructions on how to pay:

curl -s -o /dev/null -w "%{http_code}" -X POST \
  https://agent-premium.example.com/ \
  -d '{"jsonrpc":"2.0","id":1,"method":"tasks/send","params":{...}}'

{
  "payments": [
    {
      "id": "pay_abc123",
      "description": "Analisis kredit 10 dokumen",
      "amount": "250",
      "currency": "usd",
      "receiver": "https://wallet.agent-premium.example.com",
      "network": "ethereum"
    }
  ]
}

The client reads this response, then decides: pay now, or decline. This shifts the agent interaction pattern from "everything is free" to valuable services with transparent pricing. The key point: x402 isn't a new currency — it's a layer of payment instructions on top of existing networks, so agents don't need to understand blockchain details to request payment.

#The A2A-x402 Extension: Combining Task and Payment

The x402 extension runs on top of the A2A HTTP binding. The flow is like a sequential negotiation:

1. The client sends tasks/send to the remote agent.
2. The remote agent replies with status 402 Payment Required and a payment request (as above).
3. The client makes the payment, gets proof of the transaction, then resends the task with a payment proof as part of the request.
4. The remote agent verifies the proof, runs the task, and returns the result as usual.

send-paid-task.py

import httpx
 
async def send_paid_task(url: str, task: dict) -> dict:
    async with httpx.AsyncClient() as client:
        resp = await client.post(url, json={"task": task})
        if resp.status_code != 402:
            return resp.json()
 
        payment_request = resp.json()["payments"][0]
        proof = await settle_payment(payment_request)
 
        final = await client.post(
            url,
            json={"task": task, "payment_proof": proof},
        )
        return final.json()

Note two important things in this example. First, the task remains a single unit — only the payment proof is added, not a different task structure. Second, settle_payment can be anything: calling an agent wallet, requesting user approval, or executing a contract on a payment network. This flexibility is what makes x402 cross-domain.

#Mandate and Approval: Who Approves the Spending

If every transaction has to request full approval from the user, agents will stall. The solution has two keywords: mandate and approval.

• Mandate is authorization given once and repeated: "this agent may spend up to 50 dollars per day on analysis services, without asking again."
• Approval is a one-time consent requested for transactions outside the mandate's limits — a large amount, a new receiver, or a new category.

mandate-approval.py

class PaymentPolicy:
    def __init__(self):
        self.mandates = {
            "agent-analisis": {"limit_daily": 50.0, "spent": 0.0},
        }
 
    async def authorize(self, payer: str, amount: float, receiver: str) -> str:
        mandate = self.mandates.get(payer)
        if mandate and mandate["spent"] + amount <= mandate["limit_daily"]:
            mandate["spent"] += amount
            return "approved-by-mandate"
        return await self.request_approval(payer, amount, receiver)

This pattern balances speed and control: routine transactions run without friction, while suspicious or large transactions still go through a human path. In real deployments, mandates live on the wallet or policy service side, not in the agent code — so financial decisions can be audited separately from agent logic.

#UCP and AP2: The Big Map of Agentic Commerce

x402 is a direct payment protocol between agents. On top of it, two initiatives shape agentic commerce more fully:

• UCP (Universal Commerce Protocol) — a standard that normalizes the lifecycle of commercial transactions: offers, agreements, payments, and settlement. UCP gives a common language for goods, services, and obligations between parties.
• AP2 (Agentic Payments Protocol) — focuses on the agent-to-wallet relationship: how agents represent their owner's financial interests, negotiate prices, and move value between wallets without a human typing card details.

Both are complementary to A2A: A2A handles "how agents ask for work to be done", UCP handles "what the transaction value is", and AP2 handles "how that value moves from agent A's wallet to agent B's wallet". You can think of this stack like layers in an OSI network — each deals with its own problem and doesn't care about the layers beneath.

#Trust Rails: Visa TAP and Mastercard Agent Pay

All the protocols above only mean something if there are trust rails — trusted pathways that guarantee money actually moves. This is where traditional payment institutions enter the agent world. Visa TAP (Tokenized Agent Payments) and Mastercard Agent Pay are two initiatives connecting agents to card payment networks:

• Trusted agent identity: merchants and payment providers can verify that the agent is run by a registered entity — not a rogue bot.
• Limits and risk controls: agent transactions are governed by clear, auditable limits, mirroring the controls already in place for credit cards.
• Real-world settlement: the final result of an agent transaction still lands in a bank account or ledger recognized by regulators.

agent:
  name: "payment-processor-agent"
  description: "Menerima task berbayar dengan x402"
  capabilities:
    - streaming
    - push
  payment:
    methods:
      - x402
      - visa-tap
      - mastercard-agent-pay
    default_currency: usd
    max_amount_per_task: 1000

In a real ecosystem, the remote agent doesn't have to choose one — it can publish an agent card with a list of payment methods and let the client pick the most convenient path. This is the power of card-based design: capabilities are published, decisions are left to the counterparty.

#Conclusion

Episode 19 places A2A in the context of the agent economy: HTTP 402 becomes the signal for "pay first, work later", the x402 extension wraps the payment proof into the task flow you already know, mandate and approval keep spending under control, and UCP plus AP2 provide the big map of agentic commerce — while the trust rails from Visa and Mastercard ensure value really moves in the real world.

Here's the core takeaway:

• HTTP 402 is the bridge between agent tasks and payment; its response contains a structured payment request.
• The x402 extension attaches to the existing A2A flow — the client just adds a payment proof when resending the task.
• Mandates for routine transactions, approvals for large or unfamiliar ones — both must be audited separately.
• UCP normalizes transactions, AP2 connects agents to wallets, A2A connects agents to agents.
• The trust rails from Visa and Mastercard bring identity and settlement from the traditional payments world into the agent ecosystem.

In episode 20 we turn from money matters to operational matters: policy-as-code and automation — deploying agents with CI/CD, testing multi-agent systems in the pipeline, contract testing for agent cards, and governance of versions and SLAs. See you there!