Make Machine Payments with MPP

The Machine Payments Protocol (MPP) is a session-based HTTP 402 payment protocol co-authored by Stripe and Tempo. MPP enables machines to pay for services with a three-step flow: challenge, credential, receipt. In this tutorial, you'll create a payment challenge, verify a payment, and understand session management for streaming micropayments.

Prerequisites

• A wallet with TNZO balance (or USDC/USDT for payments)
• A registered identity on Tenzro Network (see Create an Agentic Wallet)
• Basic understanding of HTTP 402 payment protocols
• Access to the Tenzro MCP server at https://mcp.tenzro.network/mcp

What is MPP?

The MPP Flow

MPP uses a four-step protocol for payment verification:

Step 1: List Available Payment Protocols

First, let's verify that MPP is available on the Tenzro Network:

curl -s -X POST "https://mcp.tenzro.network/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: ${SESSION_ID}" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_payment_protocols",
      "arguments": {}
    }
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Available payment protocols:\n\n1. mpp - Machine Payments Protocol (session-based, streaming)\n2. x402 - Coinbase x402 Protocol (stateless, one-shot)\n3. native - Direct Tenzro settlement (on-chain)"
      }
    ]
  }
}

Step 2: Create a Payment Challenge

Now let's create an MPP payment challenge for accessing an AI inference endpoint:

curl -s -X POST "https://mcp.tenzro.network/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: ${SESSION_ID}" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "create_payment_challenge",
      "arguments": {
        "protocol": "mpp",
        "resource": "/api/inference",
        "amount": 1000000,
        "asset": "USDC",
        "recipient": "0x0000000000000000000000000000000000000001"
      }
    }
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{
  \"challenge_id\": \"mpp_chal_1a2b3c4d5e6f\",
  \"protocol\": \"mpp\",
  \"resource\": \"/api/inference\",
  \"amount\": 1000000,
  \"asset\": \"USDC\",
  \"recipient\": \"0x0000000000000000000000000000000000000001\",
  \"expires_at\": 1735190400,
  \"mpp_session_id\": \"sess_9f8e7d6c5b4a\",
  \"mpp_challenge_nonce\": \"nonce_a1b2c3d4e5f6\",
  \"mpp_server_signature\": \"0xabcdef123456...\"
}"
      }
    ]
  }
}

The challenge includes MPP-specific fields like mpp_session_id and mpp_challenge_nonce that enable session management and replay protection.

Step 3: Generate a Payment Credential

To pay for the resource, your agent must sign the challenge with its wallet. In a real implementation, this would happen automatically, but for this tutorial we'll construct the credential manually:

# The credential includes:
# - challenge_id: Links back to the original challenge
# - payer_did: Your TDIP identity
# - payer_address: Your wallet address
# - amount: Must match challenge amount
# - asset: Must match challenge asset
# - signature: Cryptographic proof of payment capability

# Example credential structure:
{
  "challenge_id": "mpp_chal_1a2b3c4d5e6f",
  "payer_did": "did:tenzro:machine:controller:agent-001",
  "payer_address": "0xYOUR_WALLET_ADDRESS",
  "amount": 1000000,
  "asset": "USDC",
  "signature": "0xYOUR_SIGNATURE_OF_CHALLENGE"
}

Step 4: Verify the Payment

The service provider verifies the credential and issues a receipt:

curl -s -X POST "https://mcp.tenzro.network/mcp" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Mcp-Session-Id: ${SESSION_ID}" \
  -d '{
    "jsonrpc": "2.0",
    "id": 3,
    "method": "tools/call",
    "params": {
      "name": "verify_payment",
      "arguments": {
        "challenge_id": "mpp_chal_1a2b3c4d5e6f",
        "protocol": "mpp",
        "payer_did": "did:tenzro:machine:controller:agent-001",
        "payer_address": "0xYOUR_WALLET_ADDRESS",
        "amount": 1000000,
        "asset": "USDC",
        "signature": "0xYOUR_SIGNATURE"
      }
    }
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{
  \"verified\": true,
  \"receipt\": {
    \"receipt_id\": \"rcpt_f6e5d4c3b2a1\",
    \"challenge_id\": \"mpp_chal_1a2b3c4d5e6f\",
    \"payer_did\": \"did:tenzro:machine:controller:agent-001\",
    \"amount\": 1000000,
    \"asset\": \"USDC\",
    \"timestamp\": 1735186800,
    \"mpp_receipt_signature\": \"0x987654321fedcba...\"
  },
  \"settlement_tx\": \"0x1234567890abcdef...\"
}"
      }
    ]
  }
}

The receipt serves as cryptographic proof that payment was completed. The settlement_tx is the on-chain transaction hash where funds were transferred.

Understanding MPP Sessions

MPP sessions enable streaming payments for continuous services like AI inference. Instead of creating a new challenge for every API call, a session is opened once, and subsequent payments within the session are batched and settled efficiently.

Identity-Bound Payments

All MPP payments on Tenzro are tied to TDIP identities. When a machine agent makes a payment, the protocol automatically enforces the agent's delegation scope:

• max_transaction_value: Payment amount cannot exceed this limit
• max_daily_spend: Cumulative daily spending is tracked and enforced
• allowed_payment_protocols: Must include "mpp" to use MPP
• allowed_operations: Must include the relevant operation (e.g., "inference")
• allowed_chains: Restricts which chains the agent can settle on

This ensures that autonomous agents can only spend within the permissions granted by their human controller or guardian identity.

Comparing MPP vs x402

Choose MPP for long-running or streaming services where you want to minimize per-transaction overhead. Choose x402 for simple, discrete API calls where stateless verification is preferred.

What's Next?