AgentCap

← Blog

x402 facilitator vs resource server: who shows up on-chain, and what counts as your spend

GetAgentCap team · published 10/2/2026

An x402 payment involves three parties, but only some of them appear in the token transfer. If you count spend from the wrong field, you either miss payments or credit them to the wrong counterparty.

Three roles in one payment

The client (your agent) asks for a resource and gets back an HTTP 402 response that lists the payment requirements. The agent signs a payment payload and retries the request with that payload attached.

The resource server can verify and settle the payment itself, or hand that work to a facilitator. A facilitator is a service that checks the signed payload and broadcasts the settlement transaction.

Transaction sender is not the payer

On Base, settlement usually calls USDC's transferWithAuthorization. The facilitator sends the transaction and pays the gas, so the transaction's from field is the facilitator, not your agent.

The money moves from the authorizer in the signed message, which is your agent's wallet. If you index by transaction sender, your agent's payments look like they came from someone else.

Read the Transfer event instead

The USDC Transfer event records the actual token movement: from your agent's address, to the pay-to address named in the payment requirements, for the stated amount. That event is the spend record.

Gas paid by the facilitator is not your spend in USDC terms. Count it separately if your setup reimburses gas, but do not mix it into the token total.

Solana follows the same principle

On Solana, the fee payer for a transaction can be an account other than the token owner. The token movement shows up as a transfer between token accounts, and the owner of the source account is the payer.

So the signer list and the fee payer are not enough to tell you who paid. Resolve the source token account to its owner.

How GetAgentCap attributes it

We watch the public addresses you add and record USDC transfers where those addresses are the token-level sender. Who submitted the transaction doesn't change whose spend it is.

This works the same whether a resource server settles directly or through a facilitator, and it needs nothing beyond public addresses.