Agent payment paths
27 August 2026
Pay a person. Buy a result. Keep the contracts clear.
How Hilt separates direct PayMe MPP payments to verified handles from x402 V2 purchases of protected API output on Solana.
The release
An agent payment should finish a useful job.
Wallet capability is only the beginning. A usable system must tell an agent exactly who or what it is paying, preserve the payment identity across retries, verify settlement and return an outcome another machine can trust.
Hilt now exposes two live public paths for those different jobs. PayMe MPP lets a wallet-capable agent pay a verified recipient. Hilt's x402 V2 flow lets an agent purchase protected API output. They share Solana settlement and Hilt receipts, but they do not pretend that a person-to-person payment and an access decision are the same thing.
Choose by outcome
Two live contracts. No blurred boundary.
Pay a verified recipient
PayMe MPP
A wallet-capable agent resolves an active verified PayMe handle, validates exact SOL or Solana USDC terms, signs under its wallet policy and receives a machine-readable payment receipt.
POST api.hilt.so/v1/pay-me/payments
Finalized payment + receipt
Buy a protected result
x402 V2
An agent calls a protected resource, pays its Solana USDC requirement, retries safely and receives the result only after settlement and atomic usage consumption succeed.
POST www.hilt.so/v1/solana/transaction-evidence
Paid API result + operating record
PayMe MPP runtime
From handle to receipt.
Resolve the active verified handle
Return an MPP HTTP 402 charge
Validate recipient, asset, amount, fee and expiry
Sign the exact Solana transaction under wallet policy
Retry the unchanged request
Return the finalized Hilt receipt
The recipient receives the requested amount. The sender sees and funds Hilt's flat 2% fee in the same buyer-signed transaction. No payer PayMe account, OAuth grant or Hilt API key is required.
Paid-resource runtime
From challenge to result.
Call the protected API resource
Receive an x402 V2 payment requirement
Validate and approve the Solana USDC terms
Retry with the payment signature
Settle, issue receipt and atomically consume usage
Return the protected result
Hilt's public Transaction Evidence resource demonstrates this loop for 0.05 USDC. It returns normalized facts from one finalized Solana transaction and does not claim that a transaction, token or counterparty is universally safe.
Security boundaries
Machines should not have to guess what payment means.
A receipt is not an entitlement
PayMe MPP proves that a verified recipient was paid. It does not authorize access to an unrelated API or protected resource.
A protocol is not a settlement rail
MPP and x402 describe HTTP payment interactions. Solana is the network; SOL or Solana USDC is the settlement asset used by the relevant flow.
The wallet remains the authority
Hilt never receives a seed phrase or private key. The agent or payer validates the complete terms and signs through its own wallet policy.
The result comes last
For paid resources, payment alone is not permission to serve. Settlement and atomic usage consumption must succeed before billable output is returned.
Build from the live contracts
Start with the outcome your agent needs.
Use PayMe MPP when the outcome is a direct payment and receipt. Use Hilt Pay API when the seller needs payment-to-access state around its own API, tool or dataset. Use Transaction Evidence when you want to exercise a complete live paid-resource loop without first operating the protected service yourself.