> ## Documentation Index
> Fetch the complete documentation index at: https://docs.payzor.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Pay as an agent

> How any agent from any startup pays for a Payzor product — with a Payzor wallet key, or on-chain USDC with no Payzor account at all.

# Pay as an agent

**Do you need a Payzor account to pay? No.** Any agent from any startup can pay for a product a business sells. There are two paths, and which one you take depends only on one thing: do you want to pay from a Payzor wallet, or from a plain on-chain wallet?

| Your agent's setup                                                                 | How it pays                                                                               | Payzor account needed? |
| ---------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------- |
| Has a Payzor **wallet** (`pz_sk_`)                                                 | `POST .../pay` with a Bearer key, debited from its wallet, checked against its own policy | Already has one        |
| Has any **on-chain wallet** with USDC (MetaMask, Phantom, a custodial hot wallet…) | x402: sign a USDC transfer and send it in the request                                     | **No**                 |

The second row is the key one. **An agent that is not a Payzor user pays on-chain, and it does not authenticate to Payzor at all** — it proves who it is by signing money on the chain. No card, no account creation, no API key.

## Prerequisites

You need the checkout URL the business gave you (`/checkout/:token`), and depending on the path:

* **Wallet path**: a Payzor agent API key (`pz_sk_...`).
* **On-chain path**: a wallet with USDC on a network Payzor accepts, and the ability to sign a payment payload.

## Path A — You have a Payzor wallet

If your agent already runs on Payzor, pay from its wallet. Its **own spending policy** applies: the payment is checked against per-transaction caps, daily limits and category allowlists, and pauses for human approval if it's over the threshold.

```bash theme={null}
curl -X POST https://api.payzor.com/checkout/<token>/pay \
  -H "Authorization: Bearer pz_sk_..."
```

```json theme={null}
// 200 — paid
{ "paid": true, "charge": { "chargeId": "chg_...", "status": "paid", "method": "ledger" } }
```

```json theme={null}
// 402 — over the agent's human-approval threshold
{ "pendingApproval": true, "reason": "Amount exceeds approval threshold", "approvalId": "apr_..." }
```

<Tip>
  The API key IS the identity. Whoever holds it spends from that wallet, so keep
  it out of logs and rotate it if it leaks.
</Tip>

## Path B — You're not a Payzor user (on-chain)

This is how **any agent from any startup** pays. It's HTTP-native: you ask, the server answers with the price, you sign a USDC transfer and retry, and it's settled. **No account, no Payzor citizenship, no API key.**

```bash theme={null}
# 1. Ask: you get a 402 with the payment requirements
curl -X GET https://api.payzor.com/checkout/<token>/x402

# 2. Sign a USDC payment and retry with X-PAYMENT to settle
curl -X POST https://api.payzor.com/checkout/<token>/x402 \
  -H "X-PAYMENT: <base64url signed payload>"
```

The x402 facilitator verifies the signature and funds on-chain, then moves the USDC from **your** wallet to the business. The only thing you needed was a wallet that can hold and transfer USDC — not a Payzor account.

<Accordion title="What does signing actually mean?">
  Payzor doesn't host or know your wallet. When you get the `402`, it includes the
  payment requirements — amount, network, destination address. Your agent builds a
  **USDC transfer authorization**, signs it with its own wallet key (the same process
  it would use to move funds anywhere), and sends that signature in the `X-PAYMENT`
  header. Payzor checks the signature against the chain, sees the funds are there,
  and settles. Your wallet was the identity all along.
</Accordion>

## What you get back

Either path settles the **same charge** on the merchant side and fires a webhook (`charge.succeeded` / `payment.succeeded`). The resource you paid for is yours; the business is notified automatically. The merchant doesn't care which path you used — the balance is credited the same way.

## A single link, many agents

A checkout link is reusable: each paying agent materializes its own charge. If ten agents from ten different startups pay the same link — some with Payzor wallets, some on-chain with no Payzor account — you get ten charges and the merchant sees ten settlements.

## Choosing your path

* Do you want the payment to go through **your Payzor spending policy** (caps, categories, human approval)? Use Path A.
* Do you have **no Payzor account but a wallet with USDC**? Use Path B — that's the "any startup" path.

## Checklist before paying

* Wallet path: `curl -X POST https://api.payzor.com/checkout/<token>/pay` with `pz_sk_`.
* On-chain path: `GET .../x402` returns a `402`? Then sign and retry with `X-PAYMENT`.
* Over your own approval threshold? The payment pauses until a human at *your* startup approves it — it doesn't auto-settle.

## Related

* [Checkout reference](/api-reference/checkout) — the full endpoint details.
* [x402 payments](/concepts/x402) — how on-chain HTTP payments work.
* [Accept a payment](/guides/accept-a-payment) — the merchant side.