MPP payments
The Machine Payments Protocol (MPP) enables crypto-native, per-request payments on the Tempo blockchain. MPP is an additive payment method alongside Stripe and session-based billing — you choose which to use on each request.How it works
MPP uses an HTTP 402 challenge/response flow:- You send a request to the gateway.
- The server returns
402 Payment Requiredwith a challenge containing the price, token, and recipient. - You sign a Tempo transaction matching the challenge.
- You retry the request with the signed transaction as a credential in the
Authorizationheader. - The server verifies the payment on-chain and returns the response with a
Payment-Receiptheader.
Supported networks
| Network | Chain ID | RPC URL | Status |
|---|---|---|---|
| Tempo Mainnet | 4217 | https://rpc.tempo.xyz | Active |
| Tempo Testnet | 42431 | https://rpc.moderato.tempo.xyz | Active |
Set
TEMPO_TESTNET=true in your environment to use the testnet during development.Plugin pricing
Each plugin has a fixed per-request price in USD, settled in pathUSD on Tempo.| Plugin | Price per request | Description |
|---|---|---|
agent | $0.05 | Agent orchestrator |
generate-text | $0.01 | LLM text generation |
tts | $0.03 | Text-to-speech synthesis |
stt | $0.02 | Speech-to-text transcription |
Payment credential
After receiving a 402 challenge, build and sign a credential to send with your retry:Authorization header format
Credential structure
| Field | Type | Description |
|---|---|---|
scheme | string | Always Payment |
transaction | string | Hex-encoded signed Tempo transaction (prefixed with 0x76 type marker) |
challengeNonce | string | The nonce value from the 402 challenge (replay protection) |
402 challenge structure
When a payment is required, the server responds with:Challenge fields
| Field | Type | Description |
|---|---|---|
scheme | string | Always Payment |
amount | string | Price in USD |
currency | string | Token contract address (pathUSD) |
recipient | string | Wallet address to pay |
description | string | Human-readable description of the charge |
nonce | string | Unique nonce for this challenge (used for replay protection) |
expiresAt | number | Unix timestamp (ms) when the challenge expires. Challenges are valid for 5 minutes. |
Verification
The server verifies your credential by checking:- The transaction is hex-encoded and starts with the
0x76type marker. - The recipient address matches the expected recipient.
- The token address matches the expected currency (pathUSD).
- The amount matches the plugin price (within a 0.0001 tolerance).
- The nonce matches the original challenge nonce.
Receipt
On success, the server returns:- A
Payment-Receiptresponse header containing the transaction hash. - The
payment.receiptfield in the JSON response body.
Client usage
UsemppFetch to handle the full 402 flow automatically:
mppFetch options
| Option | Type | Required | Default | Description |
|---|---|---|---|---|
plugin | string | Yes | — | Plugin ID to call |
body | object | Yes | — | Request body forwarded to the plugin |
privateKey | string | Yes | — | Hex-encoded private key for signing Tempo transactions |
baseUrl | string | No | https://agentbot.raveculture.xyz | Agentbot instance URL |
stream | boolean | No | false | Request a streaming response |
testnet | boolean | No | false | Use Tempo testnet instead of mainnet |
mppFetch result
| Field | Type | Description |
|---|---|---|
success | boolean | Whether the request succeeded |
data | object | Response body (non-streaming) |
stream | ReadableStream | Response stream (streaming) |
receipt | string | Payment receipt hash |
error | string | Error message on failure |
Check MPP support
You can check whether an endpoint supports MPP payments:OPTIONS request and checks for a WWW-Authenticate: Payment header.
Sessions
Payment sessions provide off-chain, per-call billing without an on-chain transaction for every request. This reduces latency to sub-100ms per call while still settling on-chain periodically.How sessions work
- Open a session — deposit pathUSD (minimum 100.00) into escrow via
POST /api/wallet/sessions. You can also fund your session via Stripe using the wallet top-up endpoint. - Make gateway requests — send requests to the gateway with
X-Session-IdandX-Wallet-Addressheaders. The gateway auto-debits your session balance via an off-chain voucher on each call. You can also submit vouchers directly viaPOST /api/wallet/sessions/voucher. - Automatic settlement — when accumulated vouchers reach $5.00 or after one hour, the server batches them into a single on-chain transaction.
- Close the session — call
DELETE /api/wallet/sessions?sessionId=ses_...to settle any remaining vouchers and return unused funds.
Session configuration
| Parameter | Value | Description |
|---|---|---|
| Minimum deposit | $1.00 | Minimum amount to open a session |
| Maximum deposit | $100.00 | Maximum amount per session |
| Settle threshold | $5.00 | Accumulated voucher total that triggers on-chain settlement |
| Settle interval | 1 hour | Maximum time between on-chain settlements |
Session states
| State | Description |
|---|---|
active | Session is open and accepting vouchers |
settling | Vouchers are being settled on-chain (temporary) |
closed | Session has been closed and remaining funds returned |
When to use sessions vs. per-request MPP
- Sessions are ideal for high-frequency agent calls where sub-100ms billing latency matters (e.g., chat, real-time orchestration). The gateway auto-debits your session on each call when you provide
X-Session-IdandX-Wallet-Addressheaders. - Per-request MPP (the standard 402 flow) is better for infrequent or large-value calls where on-chain settlement per request is acceptable.
Troubleshooting
402 response with no MPP challenge
402 response with no MPP challenge
The plugin may not have a configured price. Only plugins listed in the pricing table above support MPP payments.
Credential verification failed
Credential verification failed
- Ensure the
challengeNoncematches the nonce from the 402 response. - Verify the transaction amount matches the challenge amount exactly.
- Check that you are using the correct network (mainnet vs. testnet).
Transaction type error
Transaction type error
The transaction hex must begin with
0x76 (the Tempo transaction type marker). Ensure your signing implementation includes this prefix.