OAuth and x402 both show up in the same sentence as "how agents authenticate to APIs," but they answer different questions. OAuth answers "who is this acting on behalf of, and what did that person consent to?" x402 doesn't ask that question at all — it only asks "did this specific call pay what it owes?" Confusing the two leads to picking the wrong tool.
OAuth exists to let an application act on behalf of a specific person, with that person's explicit, scoped, revocable consent. A human clicks "Allow," a token is issued, and every subsequent call carries an identity: this request is happening as that person, within whatever scopes they granted. That's exactly right when an agent needs to read a specific person's real Gmail, or post to a specific person's real social account. The identity is the point.
x402 doesn't establish identity at all. A call either includes a valid signed payment for the resource it's requesting, or it gets a 402 telling it what that payment should look like. See how a 402 response actually works. There's no concept of "acting on behalf of," no consent screen, no scopes — just "this specific request paid for itself." That's exactly right when the caller doesn't need to prove who it is, only that it's allowed to use this one resource, once.
OAuth's human-consent step is a feature when a human is present to consent. It's a hard blocker when the caller is an autonomous agent with nobody to click "Allow." See designing APIs that assume the caller is a machine. x402 has no equivalent step to get stuck on, because it never asked for consent in the first place — only payment.
An OAuth token can be revoked by the person who granted it, at any time, which is one of its real strengths — access can be cut off without touching the API itself. An x402 payment has nothing to revoke; it authorized exactly one already-completed action and nothing more. A wallet secret sits in between — see API keys vs wallet secrets vs x402 signatures for where that fits.
No — and this is the important boundary. x402 can't grant access to an existing person's existing account, because it was never designed to carry identity or consent in the first place. If the task is "read Jane's real Gmail inbox," that requires Jane's consent via OAuth, full stop. x402 is for a different shape of problem: resources like a freshly provisioned agent inbox that don't belong to anyone in particular and just need to be paid for to be used.
If the question is "who is allowed to act as this specific person," use OAuth. If the question is "did this request pay for the resource it's using," use x402. They're not competing standards for the same problem — they're answers to two different questions that happen to both involve the word "authorization."
In principle, yes, for systems that need both properties at once — an agent that needs to prove both "I'm authorized to act for this person" and "I paid for this specific call." In practice, most systems need one or the other, not both, because the underlying situations rarely overlap: delegated access to an existing account is a different problem than paying for a resource that doesn't belong to anyone yet. Treating them as competing standards for the same job is the mistake to avoid — they're answers to different questions that happen to both live in the Authorization header.
If you're designing an API an agent will call, the useful question isn't "OAuth or x402" in the abstract — it's "does this resource belong to an existing identity that needs to consent, or is it something that just needs to be paid for." Resources in the first category need OAuth, full stop. Resources in the second category are exactly what x402 (or a wallet-secret equivalent) was built for, and reaching for OAuth there just reintroduces a human-consent step that doesn't need to exist.
If it helps to see it side by side, the header a caller sends tells you which model you're looking at:
Authorization: Bearer <oauth_access_token> // "I'm acting as this consenting person"
PAYMENT-SIGNATURE: <signed payment> // "This specific call paid for itself"Nothing about the second header identifies who's calling, and nothing about the first header proves a payment was made. They're not interchangeable, and a system that needs both properties has to carry both headers rather than picking one to stand in for the other.
An OAuth access token typically lives for a fixed window before a refresh token renews it — a deliberate middle ground between convenience and limiting exposure if a token leaks. An x402 payment signature has no lifetime in that sense at all: it either settles once against the specific call it was created for, or it doesn't settle. There's no refresh step and no expiry to track, because nothing about it was ever meant to be reused in the first place.