visitor@x402card:~$ explain flow

How x402card works

x402card authenticates the owner with an EVM wallet signature. A payer sends USDC on Base through an x402 payment request. After settlement is confirmed, x402card records the payment and creates a separate job that funds the owner's virtual card.

Last verified against production architecture: 2026-07-12.

The complete flow

  1. Wallet ownership. The owner requests a short-lived challenge, signs it with an EVM wallet, and receives a scoped x402card session. There is no email/password account.
  2. Card state. x402card retrieves the wallet's card or creates a paid card-issue order when public issuance and provider gates allow it.
  3. Payable URL. The owner creates an order. The returned URL answers with HTTP 402 Payment Required and exact Base-USDC payment requirements.
  4. Settlement. A payer agent signs the payment and retries the same URL. The facilitator verifies and settles it on Base.
  5. Materialization. x402card stores durable settlement evidence exactly once. Ambiguous provider results are not treated as success.
  6. Card funding. A worker uses the pre-funded provider USD float to top up the card. Received Base-USDC remains treasury inventory until operator rebalancing.

Settlement is not the same as card credit

settled

The USDC payment has authoritative settlement evidence.

funding

A separate idempotent provider job is processing the card top-up.

funded

The provider has confirmed the card funding result.

operator review

An ambiguous or delayed state is held for safe review instead of being replayed blindly.

Current payment rail

For machine-readable discovery, see the agent contract, OpenAPI, and the well-known agent descriptor.