Skip to content

root / tags / plafond-de-depense

#plafond de dépense

2 fiches

Economy & Market Auto-verified translation

Announcing Cloudflare Wallets: the programmable wallet for the agentic Internet

Product announcement published on the **Cloudflare** blog on **August 4, 2026** by **Will Papper**, as part of **Agents Week**: **Cloudflare Wallets**, presented as *"the programmable wallet for the agentic Internet"*. **The problem stated** is precise and well chosen: an agent that wants to try an API has to go through a login page **designed for humans**, have a human add a payment method, generate an API key, then figure out how to call the service. Two structural gaps explain this — *"Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs"* — with the consequence that *"AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans"*. **The proposed architecture comes down to two wallet types**: **Account Wallets**, intended for humans who own a Cloudflare account (fund, delegate, withdraw), and **Virtual Wallets**, intended for agents, **operating via API key** and whose spending cap is **set by the account holder**. The announced guardrails are explicit: **allocation, allow list, maximum amount per transaction**. **The payment rail is the x402 protocol** (payments attached to HTTP requests) and the currency is **stablecoin** — which places the offering in a distinct camp from schemes built on card networks. **The most interesting argument is counterintuitive and central**: *"These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000."* → **the cap is not what constrains autonomy, it is what makes it acceptable.** **Second component, more strategic than the first**: identity, via a **`cloudflare.pay`** namespace — a research agent could live at `research.example.cloudflare.pay`, giving the merchant certainty that it is talking to the agent of an identified organization. Cloudflare claims a deliberately minimal ambition (*"a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS"*), built on its existing building blocks (**Turnstile**, Bot Management, **Web Bot Auth** and its keypairs), and states its intent to adopt the schemes of the **x402 Foundation** as they emerge. **A decisive caveat about the status of the text**: **almost everything is in the future tense**. What exists on the day of the announcement is the **reservation of a handle**; payments, Virtual Wallets, guardrails, and the ramps for accessing funds are announced (*"Soon, you will be able to…"*). This is a **staking of position on a namespace**, more than a service going live.

#Cloudflare Wallets#agentic commerce#Agents Week

**Will Papper** — auteur de l'annonce sur le blog Cloudflare (lecture annoncée : 8 minutes). Publication rattachée à l'**Agents Week** de Cloudflare et étiquetée *Agents Week · AI · AI Bots · Developer Platform · Developers · Payments · Product News · x402*.

Economy & Market Auto-verified translation

Giving agents the ability to pay

Product announcement published on the **Stripe** blog on **April 29, 2026** by **Dan Hill** (Product Manager, Link Consumer Product), following on from the **Stripe Sessions 2026** keynote: the launch of **Link's wallet for agents**, built on a new building block, **Issuing for agents**. **The diagnosis fits in one sentence, and it is the most important one in the text**: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* → **Stripe acknowledges that machine-native payment protocols are not ready, and delivers a workaround for existing rails rather than a bet on new ones.** **The mechanism**: a consumer grants an agent access to their Link wallet via a **standard OAuth flow**; the agent then issues a *spend request* and receives either a **single-use card**, or a **Shared Payment Token** — backed by the cards and bank accounts already present in the wallet. Cardinal point: *"The agent never gets access to your raw payment credentials."* The credential is **scoped** (amount, currency, merchant) and the agent must supply the **transaction context** so the human understands what they are approving — the example given in the CLI is explicit: `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **The structuring constraint is temporal, and it is owned as such**: *"Today, each request requires the person's review before the credential is shared with your agent"* — **human** approval, **transaction by transaction**, on the web or in the **new Link iOS and Android apps**. Spending limits and cases where the agent would act **without additional approval** are announced, not delivered. **The second layer is the real infrastructure product**: **Issuing for agents** opens the full set of Issuing APIs to anyone building their own agentic wallet — single-use virtual cards, fund storage, spend controls, card-level permissions, **at-authorization** antifraud controls, real-time visibility. Four use cases are cited: internal spend automation, agentic cards embedded at **fintechs**, **vertical SaaS** platforms issuing cards to SMBs under their own brand, **marketplaces** whose selling agents pay suppliers and logistics. **Distribution argument**: Link claims **more than 200 million consumers**, and the article cites **OpenClaw** as an example of a personal agent that benefits. **Two reservations worth flagging up front**: per-transaction approval is presented as a design convenience when it is actually **an admission that delegated agent authorization is not solved**; and stablecoin, *agentic tokens*, and "other payment methods" are all in the **future tense** (*"coming soon"*).

#Stripe#Link#wallet for agents

**Dan Hill** — Product Manager · **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe · rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public** · pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.