The problem

You want your AI agent to receive stablecoin payments, to be paid in USDC for a service it provides, or to accept inbound payments like tips or sponsorships, but you are not sure how an agent gets paid. Paying out from an agent is one thing; having an agent receive money is another, and the mechanics are less obvious. You have a capable agent and a reason for it to earn, but no clear path for the stablecoin to actually reach it.

This is the receive-stablecoin problem, viewed from the agent that is being paid. The good news is that receiving is well-supported and comes in two shapes depending on whether the payment is per-call or one-off, and both land USDC in the agent's wallet. The symptom is wanting the agent to be paid in stablecoin without a clear method; the fix is to choose the right one of two receive paths and wire it, then confirm the inbound payments and decide what the agent does with them.

Two ways to receive

An agent receives stablecoin in one of two ways, and which you use depends on the kind of payment. The first is per-call earning: the agent provides a service, and callers pay per request to use it. This is the metered, ongoing case, an API, a tool, an MCP server that charges per call, and it is handled by gating the service route so each call settles in USDC before running. The second is one-off payments: someone sends the agent a single amount, a tip, a sponsorship, a payout, not tied to a specific call.

These two cover the receive side. Per-call earning is for revenue from a service the agent sells; one-off is for voluntary or single inbound payments. Some agents use only one, an API agent earns per call, a community agent receives tips, and some use both, earning per call while also accepting tips. Identifying which kind of payment you want the agent to receive tells you which method to set up, since the per-call and one-off paths differ in mechanism even though both deliver USDC to the agent.

The fix

For per-call earning, the fix is to gate the agent's service route with the x402 adapter, createX402Plugin (Fastify) or createX402Middleware (Express), with a price. An unpaid call gets a 402, the caller settles in USDC on Base, and the agent's service runs, with the payment landing in the agent's wallet. The agent earns per call from any caller that speaks x402, with no signup required of the payer. The receive-side options are detailed in best-way-to-accept-payment-from-ai-agent.

For one-off payments, the fix is to share the agent's public profile URL, which doubles as a payment link. Anyone can open it and send USDC to the agent's wallet, with no per-call gating, suited to tips, sponsorships, and payouts. Both methods deliver the same thing, USDC into the agent's wallet, and both produce a payment.received event you verify and record. So the fix to receive-stablecoin is to pick the path matching your payment kind, gate a route for per-call, share the link for one-off, and confirm via the webhook. The monetization strategy around per-call earning is in how-to-monetize-ai-agent.

Where the USDC lands

Whichever method you use, the received USDC lands in the agent's wallet, denominated in dollars. This is worth being concrete about: receiving stablecoin is not a separate balance or an external account, it is USDC arriving in the same wallet the agent uses. So once a payment settles, the agent's wallet balance reflects it, and you can see and confirm it through the payment.received event and the dashboard.

Because the received amount is a stablecoin, it is dollar-valued, which keeps accounting simple: a payment of five cents is five cents, now and later, with no volatile-asset conversion to reconstruct. The funds settle on Base, on testnet during development and mainnet in production, and the network is read from the key prefix. The practical upshot is that an agent receiving stablecoin simply accumulates USDC in its wallet, payment by payment, as a dollar balance you can track, which is the clean outcome the receive setup produces.

What the agent does with it

Received stablecoin is balance in the agent's wallet, so the agent can do a few things with it. It can hold it, simply accumulating earnings. It can spend it on its own paid calls, an agent that earns per call and also pays for data or tools can fund those payments from what it earns, becoming partly or fully self-funding. Or you can off-ramp it, converting the USDC to dollars in a bank account through a conversion service if you want the earnings in a traditional account rather than on chain.

Which you do depends on the agent's role. A service agent that earns more than it spends might accumulate a surplus you periodically off-ramp; an agent that both earns and pays might run on its earnings, topping up only when needed. The key point is that received stablecoin is ordinary USDC balance, usable for the agent's own payments or withdrawable like any stablecoin, so receiving is not a dead end but a balance you direct. Deciding what the agent does with its earnings is part of designing a receiving agent, alongside wiring how it gets paid.

Per-agent attribution

When an agent receives stablecoin, the payments are attributed to that agent, which matters if you run several. Each agent has its own wallet, so each agent's earnings accumulate separately and the payment.received events are tagged to the agent that earned them. That gives you per-agent revenue visibility: you can see which agents earn, how much, and from what, rather than a single undifferentiated pool.

This per-agent attribution is the same isolation that benefits the spending side, applied to earnings. It keeps a high-earning agent's revenue distinct from a low-earning one's, supports per-agent accounting and reporting, and means an agent's earnings are clearly its own. So as you set up agents to receive stablecoin, the per-agent wallet model gives you clean attribution of revenue for free, which is what you want when reasoning about which agents are worth running and how each is performing. Receiving stablecoin and attributing it per agent go together.

Verify receiving works

Before relying on either receive path, confirm it on Base Sepolia. For the per-call path, gate a route with a sk_test_ key, have a test caller pay it, and confirm the call settles in test USDC, your service runs, and a payment.received event fires for the agent. For the one-off path, send a small test payment to the agent's profile link and confirm it lands in the agent's wallet with a matching event.

That test proves the agent can actually receive stablecoin and that your confirmation path works, before any real money is involved. If a payment does not arrive, check you are using the agent's correct route or profile URL and that both sides are on the same network. Once a test payment settles to the agent and you see the confirming event, swapping to a sk_live_ key moves receiving to Base mainnet unchanged, and the agent is ready to be paid for real.

Related reading

If your agent needs to receive stablecoin, the receive-side options are compared in best-way-to-accept-payment-from-ai-agent, and the monetization strategy for per-call earning is in how-to-monetize-ai-agent. Together they take you from wanting the agent to be paid to USDC landing in its wallet, confirmed and attributed. Pricing is on the pricing page.