Read through Stripe's MPP documentation and the thing that stands out is how deliberately narrow the scope is. The protocol handles one thing: the negotiation between an agent and a service over a single payment. Agent requests a resource, server returns an HTTP 402 with a payment challenge, agent authorizes and pays, resource is delivered with a receipt. Stateless. Per-call. Clean.
What it doesn't touch, and isn't trying to, is everything that needs to be true for that handshake to function reliably at scale. The agent needs a funded wallet before it can authorize anything. That wallet needs to stay funded as the agent runs, potentially across hundreds of calls. The builder behind the agent needs to know what each call cost and what they charged their customer for it. They need to know whether the margin is holding up. None of that is a payment protocol concern. It's a billing concern.
What's interesting here from a Credyt perspective isn't the gap. It's the clarity. MPP draws a line that's rarely been drawn clearly: the difference between a payment and a billing system. It makes that boundary explicit in a way it hasn't been before.
What the protocol actually does and doesn't do
MPP is a coordination spec. It defines how two machines agree on a price and complete a transaction, nothing more. The Stripe documentation puts it plainly: as an alternative to an API key, your agent can pay per invocation. The agent just needs a crypto wallet.
That simplicity is the point. It means any service can become payable without building an accounts system or a pricing page UI. But the "just needs a crypto wallet" line carries a quiet assumption: the wallet has money in it, the money gets replenished, and someone is tracking how it gets spent. That assumption is doing a lot of work.
Stack: Credyt (billing layer) → Stripe MPP (payment protocol) → Tempo (settlement rail)
The stack separates cleanly into three layers, each with a distinct responsibility:
Tempo handles settlement: high-throughput, sub-second finality, settles into fiat in the seller's Stripe balance. MPP handles the negotiation: the 402 challenge, the authorization, the receipt. The billing layer handles everything about the wallet sitting above it, who funded it, how much is left, what each event cost, what the margin looks like.
These are distinct domains. Conflating them is where builders get into trouble.
The 402 flow, precisely
Being exact about what MPP specifies matters here, because its simplicity makes the adjacent problem more visible:
- Agent requests a resource: A plain HTTP request to an MPP-enabled endpoint. No API key, no account required.
- Server returns HTTP 402 with payment challenge: Price, accepted payment methods (USDC on Tempo, or cards/wallets via Shared Payment Tokens), and a challenge ID.
- Agent authorizes payment from its crypto wallet: Signs the challenge. Funds move on-chain. Stripe auto-captures the PaymentIntent when settlement confirms.
- Server delivers the resource with a receipt: Transaction settles on Tempo. Appears in the seller's Stripe Dashboard like any other payment, in fiat.
- Credyt records the event and updates the wallet: Usage ingested. Balance deducted in real time. Cost logged against the vendor. Margin calculated. Customer portal updated.
As an alternative to setting up an account and getting an API key, your agent can interact with services on demand and pay per invocation. Your agent only needs access to a crypto wallet.
Steps 1 through 4 are what MPP specifies. Step 5 is what you still have to build, or what a billing system handles for you. The settlement is instant. The accounting isn't automatic.
The Stripe docs are explicit on a point that often gets missed: even though the agent pays in USDC on Tempo, the funds land in the seller's Stripe balance in fiat on their normal payout schedule. The crypto complexity is abstracted away at the Stripe layer, which means the billing layer above it can reason entirely in USD. No exchange rate headaches, no stablecoin balance reconciliation.
The microtransaction problem is a real-time problem
MPP supports charges down to 0.01 USDC per call. That number matters more than it looks. At that granularity, a single agent completing a research task might fire 50 or 100 individual MPP payments in the span of a few minutes. The total spend is legible, maybe $3, maybe $15, but it's accumulated through a long sequence of tiny transactions each settled independently on-chain.
The implications for wallet management are significant. You can't wait until end of month to bill. You can't wait until end of day. The balance needs to reflect what's actually been spent right now, because the agent is making spend decisions right now. If the wallet shows $20 but $18 of that is already committed to in-flight MPP calls, an agent that fires another request is operating on false information.
Real-time billing isn't a feature preference here. It's a correctness requirement. The wallet balance is a live number, not a snapshot.
There's a related problem that's easy to miss: 100 individual transactions is not the same thing as one task. If a customer looks at their billing history and sees a wall of line items, each for fractions of a cent, they have no idea what they actually paid for. Credyt handles this natively through what we call a Subject. When you emit a usage event, you attach it to a Subject, a task ID, a session reference, whatever maps to a meaningful unit of work in your product. All the individual calls that make up that task roll up under the same Subject, so the customer sees "research task #47: $4.20" rather than a hundred separate charges. The granularity is still there if you need to drill into it. The default view is human.
Auto top-up as a reliability primitive
There's a failure mode that's easy to overlook when you're thinking about MPP in the abstract. An agent running unsupervised will hit an empty wallet and silently fail. The 402 challenge comes back, the agent can't pay, and the task stalls. No error message the user will see. No notification that something went wrong. Just a stopped agent and a confused customer.
With a human in the loop, this is annoying but recoverable. Without one, it breaks the core promise of the whole agentic paradigm. The agent was supposed to handle this.
Auto top-up is what closes that loop. When the wallet drops below a threshold, an off-session Stripe payment fires automatically and the balance is restored before the next call fails. The agent doesn't know it happened. The customer gets a receipt. The task continues.
Think of this not as a billing feature but as a reliability contract. "This agent will not stall due to insufficient funds" is a guarantee you can make if wallet management is handled at the infrastructure level. It's not a guarantee you can make if top-up is a manual step.
What observability looks like
Agents operating in an MPP environment have a visibility problem by default. The humans who care about what the agent is doing, your customer and you, have very limited visibility. MPP transactions show up in Stripe as individual payments. That tells you money moved, not what it was for or whether the economics made sense.
The wallet view below is what a customer sees when their agent has been running against MPP-enabled services all morning. Each event is attributed to the service it called, with timestamps that match the agent's actual activity window. The auto top-up appears inline as part of the same activity log, not buried in a separate billing email.
| Event | Source | Amount | Margin |
|---|---|---|---|
| Auto top-up triggered (balance reached $8.42) | Stripe | +$50.00 | |
| web_scrape_call × 18 | MPP · scraper_api | −$7.20 | cost $1.80 · 75% |
| llm_inference_call × 6 | MPP · inference_co | −$6.00 | cost $1.80 · 70% |
| data_enrichment_call × 4 | MPP · enrichco | −$2.89 | cost $0.80 · 72% |
The margin column is the part that matters most for the builder. If one of your MPP vendors raises their per-call price, you'll see it here before you see it in your bank balance. At 0.01 USDC per call, a 20% cost increase is invisible in any individual transaction. Across 10,000 calls a day, it's not.
The agent's wallet: a crypto account alongside fiat
Credyt's wallet is multi-account by design: one wallet per customer, multiple accounts each tracking a distinct asset. For an agent operating in an MPP environment, the natural structure is a USDC account sitting alongside USD. The agent draws from USDC to authorize MPP payments on Tempo, while the USD account tracks what your platform bills the customer for each task completed.
The USDC account is linked directly to a Tempo wallet address. When a customer funds their agent by sending USDC on-chain to that address, Credyt detects the deposit and credits the account automatically. No manual reconciliation, no external monitoring. The balance is live the moment settlement confirms on Tempo.
Spend rules apply per-asset and independently. The USDC account has its own auto top-up threshold and recharge amount, separate from whatever rules govern the USD account. A customer might set a 20 USDC floor with a 100 USDC recharge, keeping the agent's MPP float topped up continuously without thinking about it. The USD account runs on different rules tuned to your platform's billing cadence. Both are configurable in the Billing Portal without any involvement from you.
Here's what that wallet looks like for an agent with both accounts active:
| Account | Available | Spend rule | Funded via |
|---|---|---|---|
| USDC (MPP payments · Tempo) | 142.80 USDC | Auto top-up at < 20 USDC, recharge 100 USDC | On-chain deposit |
| USD (platform billing) | $33.91 | Auto top-up at < $10, recharge $50 | Stripe card |
| TOKENS (bundled entitlement) | 4,200 TOK | Refreshes monthly with subscription | Entitlement |
The USDC account behaves like any other Credyt account. It appears in the billing portal, shows a transaction history of deposits and MPP spend, and fires auto top-up when the balance drops. The only difference from a USD account is the funding path: on-chain rather than card. From the agent's perspective it's just a balance to draw from. From the customer's perspective it's a funded wallet they top up by sending USDC to an address. From your perspective as the builder it's another account in the same API response.
The deposit address on the USDC account is what the customer sends USDC to. Credyt watches that address on Tempo and credits the account on confirmation. The agent can check its own balance before firing an MPP call, a simple guard that avoids a failed 402 authorization mid-task.
The wallet as a payment routing layer
MPP adoption will be uneven for a while. Some services will implement it quickly. Others won't touch it for a year, or ever. An agent operating in the real world will find itself talking to both: an inference provider that speaks MPP, and a data vendor still running on API keys and monthly invoices. The agent needs to pay both. The billing layer needs to track both.
Something the full MPP spec makes clear is that the routing decision isn't entirely the agent's to make. When a service returns a 402, that challenge declares what payment methods it accepts: crypto on Tempo, SPT via card or Link, or both. The agent responds with whichever credential matches. This means the service drives the initial selection, not the agent's balance state. The agent just needs to have the right account funded for whatever the service asks for.
That's where the multi-account wallet becomes interesting architecturally. Each account represents a distinct payment modality. USDC for services that accept crypto MPP and settle on Tempo. USD for services that accept SPT payments via card or Stripe's payment rails. TOKENS for services your platform intermediates directly, where the agent pays in your native unit and you settle downstream. The accounts are independent, each with their own balance and their own auto top-up rules, so the agent always has the right asset available for whichever method a service requires.
For services that haven't implemented MPP at all, the agent falls back to whatever that service does support: a traditional API key flow, a card charge, a token deduction. Credyt tracks all of it the same way regardless of the underlying rail. A usage event comes in with an asset and a Subject, the right account is debited, the cost is logged. The payment method is irrelevant to the accounting layer. That decoupling is what makes the wallet a composable primitive rather than a point solution for a single protocol.
The routing intelligence lives in the agent: read the 402, match the payment method, select the account, authorize. The accounting intelligence lives in Credyt: debit the balance, log the cost, update the margin. Keeping those two things in separate systems is probably the right long-term call. The payment rails will keep evolving. The accounting model doesn't need to change every time they do.
The longer trajectory here is agents making these payment method decisions autonomously at high frequency, weighing settlement speed, cost, and availability in real time across a mix of MPP and non-MPP services. The wallet structure that supports that needs to be flexible enough to hold multiple asset types, granular enough to enforce rules per asset, and transparent enough that a human can audit what the agent decided and why. That's the architecture we're building toward.
A note on what's still unsettled
MPP is new. The Stripe docs note that machine payments must be enabled per account, US-only for now, and still in an early access phase. The protocol itself is designed to be rail-agnostic. It runs on Tempo today but the spec is built to extend to other chains and payment methods over time. Visa's already extended it for card-based payments.
What that means in practice: the payment rail will continue to evolve, and the billing layer sitting above it needs to be decoupled from those specifics. The Credyt wallet doesn't care whether the underlying settlement is USDC on Tempo, a card via SPT, or something else entirely. It reasons in usage events and USD balances. That decoupling is the right long-term architecture regardless of how MPP's rail support expands.
There are also open questions that MPP doesn't resolve and billing systems don't fully resolve either. When an agent is acting on behalf of multiple humans, a workflow that orchestrates sub-agents or a shared team account, who owns the wallet? Who sets the spend limits? How does attribution work when one agent spawns another? These are product design questions as much as infrastructure questions and nobody has clean answers yet.
We're working through them with the builders we're talking to.
If you're building on top of MPP and working through the billing layer, we'd like to hear what you're running into. And if you want to see how Credyt handles this in practice, credyt.ai.