Agents don't have credit cards: three rails for machine payments

“Let the agent pay” hides the only question that matters: with whose authority?

An agent has no natural wallet, legal identity, cardholder agreement, or appetite for risk. It has whatever credential and policy a person or organization delegated to it. Payment design begins there, not at the checkout button.

OpenArtifacts is a useful case because the billable action can be tiny. A publish after the free allowance is $0.005. That is too small for a person to visit a card form every time and too consequential for an agent to invent permission after the fact.

There are three relevant approaches: a human funds credit through Stripe Checkout; an agent pays inline with x402; or an agent coordinates payment through the newer Machine Payments Protocol. They are not three interchangeable logos. They put the human, agent, merchant, and payment network in different places.

Rail one: the human funds the account first

Stripe Checkout is a hosted or embedded payment page for a person. The server creates a Checkout Session, the browser goes to Stripe, and successful payment is confirmed through Stripe's payment lifecycle. Checkout Sessions support one-time purchases and subscriptions; OpenArtifacts uses the one-time top-up shape when the card option is enabled.

The agent never sees a card number. It sees account credit and a spending policy. That separation is a feature.

The flow is:

1. A person chooses an amount in the account's credit page.
2. Stripe handles the payment experience.
3. The account receives credit after confirmed payment.
4. Agents spend from that bounded balance as they publish.

This is the conservative default for recurring work. A human makes one legible decision up front, then automation continues without a browser. It works with familiar statements, refunds, fraud controls, and accounting.

Its weakness is setup friction. The person must already have an account relationship and must interrupt work to fund it. Card economics also make true micropayments unattractive, so the top-up is larger than the next half-cent publish.

For a shared team, funding account credit is often exactly right. The owner can bound exposure, members share the allowance, and the agent never receives a general-purpose purchasing instrument.

Rail two: x402 makes payment part of HTTP

x402 is an open standard built around HTTP 402 Payment Required. A client asks for a resource, the server responds with acceptable payment requirements, the client prepares a payment payload, and it retries the request. Verification and settlement may happen directly or through a facilitator.

A simplified exchange looks like this:

POST /paid-operation

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <machine-readable requirements>

POST /paid-operation
PAYMENT-SIGNATURE: <authorized payment payload>

Header names and payloads depend on the current protocol version; use the x402 specification repository rather than this sketch to implement it.

The appeal is obvious. The price arrives where the need appears. An agent can compare accepted schemes and networks, authorize the exact request, retry, and receive the resource without opening a checkout page or establishing a subscription first.

The trust boundary moves into the wallet and its policy. Who funded it? Which assets and networks may it use? What is the per-request cap? Can it pay the same challenge twice? What happens if the payment settles but the operation fails? A wallet connected to an unconstrained agent is not autonomy; it is an unbounded bearer credential with better branding.

Stripe's current x402 machine-payment documentation describes USDC payments on Base through a resource server and facilitator, and labels the product private preview. That status matters. Protocol support, processor support, geography, network, and settlement asset are separate facts and may change independently.

Rail three: MPP coordinates more kinds of payment

The Machine Payments Protocol is an open HTTP payment standard co-authored by Tempo and Stripe. It also uses a 402 flow, but its design is organized around the Payment HTTP authentication scheme and extensible payment methods. The specification covers the conversation between client and service while payment methods can evolve underneath it.

Stripe's MPP announcement highlights microtransactions, recurring payments, stablecoins, cards, buy-now-pay-later methods, and Shared Payment Tokens. That breadth is the main contrast worth understanding: MPP aims to coordinate machine payments without declaring that every machine payment must be one on-chain exact transfer.

The high-level exchange is familiar:

agent requests resource
service returns a payment challenge
agent authorizes an accepted method
service returns the resource and a receipt

The protocol was announced in March 2026 and is moving quickly. Read the normative MPP specifications before implementing against it. A blog comparison ages; a spec has versioned obligations.

MPP does not remove delegation questions. A Shared Payment Token, stablecoin wallet, or recurring mandate still needs a human or organizational policy behind it. The protocol can standardize challenge and authorization. It cannot decide whether publishing a page is worth money to its owner.

Compare the actor at the moment of payment

With Checkout, a person is present at funding time but absent from each later publish. The spending boundary is the account balance and whatever product controls sit around it.

With x402, the agent is present at request time and typically signs or supplies a payment payload for a specific resource requirement. The boundary is the wallet mandate, supported scheme and network, and challenge amount.

With MPP, the agent is also present at request time, but the accepted instrument can be broader. The boundary is the chosen payment method's authorization model plus the protocol challenge.

That yields a practical selection rule:

• Use human-funded credit when work is repeated, the team wants a hard budget, and familiar card operations matter.
• Use x402 when the resource is naturally pay-per-request and both parties support a compatible on-chain scheme and network.
• Evaluate MPP when the service needs HTTP-native machine payment across multiple instrument types, recurring relationships, or newer agent-commerce workflows.
• Offer more than one only if each advertised rail is genuinely available and reconciles to the same product entitlement.

A 402 must be a contract, not a billboard

Whichever rail wins, the unpaid response should tell the client the exact amount, reason, acceptable methods, and retry semantics. The paid response should include a receipt that can be tied to the operation. Retries must not duplicate either payment or fulfilment.

{
  "code": "payment_required",
  "reason": "publish",
  "amount_usd": 0.005,
  "accepts": [
    {"scheme": "x402", "header": "PAYMENT-SIGNATURE", "settles_usd": 0.25, "instructions": "how to retry"},
    {"scheme": "mpp", "methods": ["stripe"], "header": "Payment-Authorization", "settles_usd": 5, "instructions": "how to retry"}
  ]
}

The rule behind that list is deliberately unglamorous: a rail appears only when that exact retry settles on this deployment. A stub with instructions would send an agent toward a payment that cannot complete. When this post was first published, OpenArtifacts offered only a local test rail and human card top-ups, and its challenge listed nothing else. Since 2026-09-24 the production 402 carries x402 (USDC on Base) and MPP (USDC on Tempo or Base, or a card through a Link wallet) for real, and each entry states what the retry settles. A rail cannot move half a cent, so USDC settles at least $0.25 and a card at least $5, and the difference stays on the account as credit.

The human moves upfront

The safest agent-payment interaction is not a confirmation dialog after every half-cent. It is a human choosing the mandate before the loop starts:

• this account may spend up to this amount;
• this agent may use these paid operations;
• no individual request may exceed this price;
• stop and ask again when the boundary is reached.

Then the agent must disclose the amount before any exceptional top-up. Receipts and usage belong in a place the human can audit. See Microdollars, arrears, and counters that cost money for the accounting principles around that boundary.

Most OpenArtifacts users need none of these rails to begin. Publishing is free without a signup form, and claiming an account unlocks 100 free publishes a month. Payment should be the edge case an agent understands, not the ceremony every idea must survive.