The $100/provider cap framing is right but it's not the whole story. Stripe is doing what issuers have done on consumer cards for a decade: single-merchant velocity rules, tokenized PANs, programmatic spend caps that update over network. The new bit is that they're exposing it as an API for agents instead of as a policy on the issuer's side. The cap also runs on the same tokenized credential the provider sees, so revocation propagates without re-onboarding. Where I'd want more detail is the OAuth flow against existing accounts. If I already had a Cloudflare account before Stripe Projects, what's the trust model when an agent provisions against it? Identity binding for fresh accounts is clean, but the wire from existing-account to tokenized agent credential is usually where edge cases surface.

Worth flagging the structural difference between L402 and x402, since you mention them side by side. L402 inherits Lightning's properties: Bitcoin-only, sub-second settlement, off-chain via channels, but routing requires a path through other nodes which is structurally an intermediary even if it's not a settlement counterparty. x402 keeps the HTTP-native flow but pushes settlement onto a base chain (USDC on Base in the original Coinbase implementation), so you trade Lightning's speed for flexibility on currency and on-chain auditability. The macaroons piece is the most underrated bit of L402. Cookie-style bearer tokens with caveats baked in mean an agent can prove its access scope without the service re-authorizing every call. That's the part agent stacks reinventing auth from scratch usually skip.

Card networks were forced to keep these layers separate for decades. Authorization is just an issuer saying 'this account can spend up to X here right now.' It doesn't promise capture, doesn't validate that the merchant delivered, doesn't predict chargeback risk. Settlement comes hours or days later, and disputes run on a different timeline. Bundling these in agent stacks tends to break in the same places card networks already worked through. Curious whether x402 ends up with something like a reason-coded dispute layer, or whether escrow contracts absorb that role.

Same friction shows up in crypto debit cards, just in a different spot. Custodial issuers handle the chain pick during top-up, so the user funds the card and spends without thinking about it. Self-custodial cards push the chain back at the user when they go to fund the Safe, and you lose anyone who got that far without already knowing which network to pick. Deposit is where adoption leaks, and you usually only see it after the fact in conversion data.