com.agentscore.payment.mpp v1

1. Introduction

Machine Payments Protocol (MPP), multi-chain. Today AgentScore merchants ship Tempo USDC + Solana USDC via solana/charge; MPP itself reaches Stellar, Lightning, and more.

AgentScore binding for the Machine Payments Protocol (MPP, mpp.dev) in UCP. The agent uses an MPP-aware client (e.g. agentscore-pay, the tempo CLI) to settle in response to a 402 challenge. The merchant's MPP server verifies the signed payment authorization and captures the funds. The `networks` array enumerates which MPP-supported networks the merchant accepts. Today: Tempo USDC + Solana USDC via `solana/charge`. Adding more MPP networks (Stellar, Lightning, etc.) is a config change, not a new handler. Shape is identical to `payment.x402.config` so consumers parse both the same way. The MPP protocol itself is specified at paymentauth.org, with developer docs at mpp.dev.

2. Configuration

The schema for the binding's `config` object lives at /schemas/payment-handlers/mpp.json. The wrapper fields (id, version, spec, schema, config) are defined by UCP itself.

Fields:

• networks (array of object): Array of MPP networks the merchant accepts. One entry per network. Must contain at least one entry. Same shape as x402.config.networks so consumers parse both handlers identically.
• networks[].network (string): MPP network identifier. Tempo: `tempo-mainnet` / `tempo-testnet`. Solana via `solana/charge`: `mpp-solana-mainnet` / `mpp-solana-devnet`.
• networks[].chain_id (integer (optional)): Optional. Numeric chain id for EVM-style chains (e.g. 4217 for Tempo mainnet, 42431 for the Tempo Moderato testnet). Omit for non-EVM networks.
• networks[].recipient (string (optional)): Optional. Merchant's static settlement address on this network. When present, agents MAY cross-check the 402 challenge's `pay_to` against this declared address as MITM protection. Omit if the merchant uses per-order recipients; the authoritative recipient still ships in the 402 body.

Example config:

{
  "networks": [
    { "network": "tempo-mainnet",       "chain_id": 4217, "recipient": "0xabc..." },
    { "network": "mpp-solana-mainnet",                   "recipient": "Ata..." }
  ]
}

3. Payment protocol

End-to-end flow from the merchant's 402 challenge to settlement:

1. 402 emit. Merchant returns 402 with accepts[] including one entry per accepted MPP chain. Tempo: { id: "tempo", network: "tempo-mainnet", currency: "USDC", amount, decimals, recipient }; Solana: { id: "solana", network: "mpp-solana-mainnet", currency: "USDC", amount, decimals, recipient }. The 402 body also carries agent_instructions.how_to_pay with the canonical agentscore-pay pay --chain {tempo|solana} commands per chain.
2. Agent prep. Agent's wallet client builds the chain-appropriate signed authorization: Tempo uses an MPP payment authorization; Solana uses an SPL TransferChecked instruction. Both target the merchant's recipient + amount + decimals from the 402.
3. Sign. Agent signs with the wallet's private key. The DID identifies the source (did:pkh:eip155:: for Tempo; did:pkh:solana:: for Solana).
4. Retry. Agent re-POSTs the original request with Authorization: Payment carrying the signed authorization.
5. Settle. Merchant validates and submits via the chain-appropriate MPP server. On success returns 200 + the original resource. On invalid payment returns 402 with a corrected challenge.

4. Server processing

Merchant-side responsibilities once the agent's payment credential arrives on the retry leg:

1. Tempo: Decode the credential payload to extract the signed payment authorization. Validate the recipient address, USDC token contract, and amount against the merchant's 402 challenge. Call mpp.charge() (e.g. via pympp.tempo or mppx) to submit the authorization to Tempo. On confirmation, capture the transaction hash for the order record. The merchant SHOULD attribute the payment to a credential or operator via the source DID (did:pkh:eip155::).
2. Solana: Decode the signed transaction from the credential payload (payload.signed_transaction). Validate the SPL TransferChecked instruction targets the merchant's expected destination ATA, mint (USDC), and amount derived from the 402 challenge. Submit via @solana/mpp/server.charge (or upstream sendTransaction RPC). On confirmation, capture the tx hash. Settlement-Overrides headers (X-Settlement-Overrides) accepted for dynamic-amount finalization.

5. Security considerations

• The MPP server MUST validate destination + token + amount against the 402 challenge it issued. Never trust client-supplied values.
• Tempo finality is fast (~2s); the reference server treats first-block confirmation as final for low-value payments.
• Solana finality: prefer confirmed commitment for low-value payments, finalized for >$100. The reference server uses confirmed by default.
• Capture the signer address (did:pkh source OR derived from the on-chain authorization) for AgentScore wallet-attribution writebacks. Required for credential↔wallet linkage on the merchant side.

See also

• Reference agent client: agentscore-pay (npm: @agent-score/pay). See docs.agentscore.com/integrations/pay-cli
• Merchant SDKs: @agent-score/commerce (Node) and agentscore-commerce (Python)
• UCP payment-handler guide: ucp.dev/specification/payment-handler-guide