Product

How a payment works

Payzilla handles one kind of payment today: x402. A web request asks for payment, the buyer pays, and the request goes through. This page follows one payment from start to finish, shows who does each step, and explains what happens when something goes wrong.

Devnet preview. Test tokens only. No real money.

Watch an agent payRead the developer reference

One payment, step by step

  1. AskBuyer

    A buyer, often an AI agent, requests something from a seller’s API or tool.

  2. 402Seller and Payzilla

    The seller’s server answers with HTTP 402 and a price: the amount, the token, the seller’s wallet and a payment id that goes in the memo. Payzilla issues this challenge and records the payment. It issues one only when the payment can be completed.

  3. PayBuyer

    The buyer signs a transfer from its own wallet and repeats the request with the payment attached. Our demo agent first checks the price and the recipient against its own limits. The tokens move from the buyer’s wallet to the seller’s wallet.

  4. Verify and settlePayzilla

    Payzilla checks the signed transfer before it does anything else: the exact shape of the transaction, the amount, the recipient, the memo, and that the network-fee account is not moving any tokens. It simulates the transaction, adds its signature as the network-fee payer and sends it to Solana devnet.

  5. ReleaseSeller

    The seller serves the resource once the payment is released. By default that is when the payment is captured for amounts up to 5 test USDC, and when it is final for larger amounts. The limit is a per-seller setting. A seller can opt in to serve earlier for low-value calls, with a cap on the exposure.

  6. LedgerPayzilla

    Every step is written to one balanced ledger. Each payment has one status you can read at any time.

Why the dots? In the Payzilla mark, the Z starts with a ring and ends with a dot. The ring is where a payment begins and the dot is where it ends: a payment from A to Z. The first and last steps above wear the same ring and dot.

The statuses

  • Authorized, Submitted, Captured, Final: the normal path, as the network confirms the transaction.
  • Failed: the payment did not complete. Nothing was served on the strength of it.
  • Reverted: a captured payment later disappeared from the network. Payzilla records it with reversing ledger entries.

Who holds what

  • The payment tokens go from the buyer’s wallet to the seller’s wallet. Payzilla does not hold them.
  • Each wallet’s key stays with its owner.
  • Network fees on devnet are paid by a fee-payer account that Payzilla runs. It holds only test SOL.
  • Payzilla is software, not a bank.

When something goes wrong

  • A repeated request carrying the same signed payment settles once.
  • If a check fails, nothing is signed or sent.
  • If nobody can pay the network fee, no challenge is issued.
  • If settlement does not complete, the seller does not serve the resource (the default mode).

Try it

Watch an agent pay on the live demo page: a demo agent makes a real test-token payment on devnet while you watch each step. Or open the dashboard demo to see payments, timelines and ledger entries with sample data, follow the steps on how to try the preview, read the developer reference, see how it is built on the security page, or read the roadmap.

Dashboard-Demo Get in touch