Skip to main content
When a client calls a Proceeds-protected URL, Proceeds returns a 402 Payment Required with a challenge. The client pays using x402, MPP, or Circle Nanopayments, retries with proof, and Proceeds verifies the payment before proxying the upstream response.

​
The five steps

1

Request

GET https://myproceeds.xyz/api/x402/pay/{serviceId}/{slug}Proceeds matches the URL to a paywall, applies HTTP method restrictions, and returns a challenge.
2

Challenge

402 Payment RequiredThe challenge advertises the price, supported networks, and accepted standards. Clients use the challenge to decide how to pay.
3

Pay

The client signs a payment authorization. Proceeds is neutral to the underlying mechanism:
  • x402: an EIP-3009 USDC authorization, attached as a header.
  • MPP: a Payment credential negotiated through an MPP-aware client like mppx.
  • Circle Nanopayments: an offchain Gateway authorization, settled in batch.
4

Retry

The client retries the request with proof of payment in the request headers. Proceeds verifies the payload before forwarding anything upstream.
5

Deliver

Proceeds proxies the request to your Target URL — with custom headers, query parameters, and upstream auth attached — and streams the response back to the client.

​
What Proceeds does at each step

​
Observability

Proceeds writes two complementary records for every protected request.
  • Transactions track payment state. Standard x402 and MPP typically land as Completed or Failed. Circle Nanopayments go Pending → Completed while Gateway settles the batch onchain.
  • Events track lifecycle steps. Proceeds emits REQUEST, SUCCESS, and ERROR events.
When a paid request behaves unexpectedly, start in Events to find the step that failed, then cross-check the matching record in Transactions.

Troubleshooting

A short playbook for the most common challenge, payment, and fulfillment failures.