The problem

You want people to be able to tip your AI agent, to send it a voluntary payment because they found it useful, want to support it, or simply choose to. But the payment setup you have is built for charging per call: an agent pays for what it calls, or charges callers for a service. A tip is none of that. It is unprompted, voluntary, and not tied to any particular call, so there is no 402 to gate and no service being purchased. You have no obvious way to receive it.

This is the receive-tips problem. The friction is that the per-call payment model, which fits services, does not fit a one-off gift, and trying to force tips through it makes no sense, you cannot gate a tip behind a paywall. The symptom is wanting to accept voluntary, one-off payments to the agent with no mechanism shaped for it. The fix is to use the right tool for inbound one-off payments, which is the payment link, not x402.

Why x402 is not the fit

It is worth being clear about why x402 is the wrong tool for tips, because the instinct is to reach for it. x402 charges per call: a caller requests something, gets a 402, and pays for that specific call. It is built around a service being consumed and paid for. A tip has none of those properties, there is no call being made, no service being bought, and no price the agent is charging. The tipper is choosing to send money, unprompted, in an amount they decide.

So gating a route with x402 to receive tips does not work: there is no request to gate, and forcing one would turn a voluntary gift into a transaction, which it is not. x402 and tipping are different shapes of payment, per-call charging versus one-off voluntary inbound. Recognizing that they are different is what points to the fix: do not try to receive tips through the per-call mechanism; use the mechanism made for one-off inbound payments, which is the agent's payment link.

The fix

The fix is to use the agent's public profile URL, which doubles as a shareable payment link. Every agent has a public profile, and that profile's URL is also where anyone can send the agent USDC. So to let the agent receive tips, you share its profile URL, and a tipper opens it and sends whatever amount they choose to the agent's wallet, with no signup and no per-call gating. The tip lands in the agent's wallet, and you learn of it through the payment.received webhook.

This fits because the link is shaped for exactly this: a one-off, voluntary, unprompted inbound payment. There is nothing to build, the profile is the link, so once the agent has a profile and wallet, it can receive tips at that URL immediately. The fix to the receive-tips problem is therefore to share the link the agent already has, not to construct a tipping system on top of the per-call rail. The link concept is covered in how-to-create-payment-link-for-ai-agent.

How to set it up

Setting up tipping is mostly sharing a URL. Find the agent's public profile URL, the link to its profile, and put it where supporters can reach it: in the agent's responses, on a project page, in documentation, wherever people who value the agent might want to tip it. There is no separate link to create; the profile URL is the payment link, so the setup is making that URL discoverable.

Then wire confirmation. Set up the payment.received webhook and verify deliveries with webhooks.verify, so each tip becomes a durable event you can record. With that, you know when a tip arrives, who sent it, and how much, which lets you acknowledge tippers or track support over time. That is the whole setup: share the profile URL as the tip link, and listen for payment.received to confirm tips. The general guidance on paying an agent, including one-off payments, is in best-way-to-pay-ai-agent.

Verify it works

Confirm tipping works by sending a test tip on Base Sepolia. Open the agent's profile URL yourself, or from a test sender, and send a small amount of test USDC to the agent. Confirm it lands in the agent's wallet and that a payment.received event fires and verifies, so you know both the inbound payment and your confirmation path work. That single test tip, sent and confirmed, proves the agent can receive voluntary payments.

If the tip does not arrive, check that you are using the correct profile URL for the agent and that the sender is on the same network, Base Sepolia for the test. If the tip arrives but you get no event, check the webhook endpoint and signature verification. Once a test tip settles to the agent and you see the confirming event, the receive-tips problem is solved, and the same flow works on Base mainnet by sending real USDC to the live profile URL.

Good uses beyond tips

The payment link solves tipping, but its real scope is any one-off or voluntary inbound payment, so it is worth knowing the adjacent uses. Sponsorship works the same way: a supporter sends the agent a larger one-off amount to back it. Payouts to the agent, someone sending it funds it is owed, use the same link. And topping up the agent's wallet, adding balance so it can keep paying for what it calls, is just another inbound payment to the same URL.

So the fix for tips doubles as the fix for a whole class of inbound payments. The dividing line is per-call versus one-off: if someone is paying for a specific service the agent provides, that is x402; if they are sending a single, voluntary, or owed amount, that is the link. Knowing the link covers tips, sponsorships, payouts, and top-ups means you reach for it whenever the payment is one-off inbound, and reach for x402 only when charging per use.

Identity helps people tip with confidence

One thing worth pairing with the tip link is the agent's verifiable identity, because a tipper is sending money to a URL and wants to know it reaches the right agent. The same public profile that serves as the payment link can carry verified badges, email, GitHub, domain, that confirm who stands behind the agent. So a supporter opening the link sees not just a place to send USDC but evidence of which agent and operator they are tipping, which makes them more comfortable sending.

This matters more for larger voluntary payments like sponsorships than for small tips, but in both cases identity turns a bare link into a trustworthy destination. So if you want people to tip or sponsor your agent with confidence, set up its identity alongside sharing the link: the link receives the payment, and the verified profile reassures the sender they are paying the agent they intend to. The two work together, the link as the mechanism and the identity as the trust, which is why a well-set-up tippable agent has both.

Related reading

If your agent needs to receive tips, the link is the tool. The concept and good uses are in how-to-create-payment-link-for-ai-agent, and the broader question of how to pay an agent, including one-off payments, is in best-way-to-pay-ai-agent. Together they take you from no way to tip to an agent that receives voluntary payments at a shareable link. Pricing is on the pricing page.