Take Bitcoin without running any Bitcoin.

An extended public key derives receiving addresses. It cannot sign a spend. Satsgate uses it to issue a fresh address per checkout and to watch that address, which is the whole of our access to your money.

# What you hand over. It can watch, and it cannot spend.
zpub6rFR7y4Q2AijBEqTUquhVz398htDFrtymD9xYYfG1m4wAcvPhXNfE3EfH1r1ADqtfSdVCToUG868RvUUkgDKf31mGDtKsAYz2oz2AGutZYs

# What you get back, per checkout.
POST /v1/checkouts  ->  a fresh address, derived at the next unused index

A fresh address identifies the checkout. For x402, keep the issued payment identifier private and bind it to the purchase. Public transaction details do not authorise access. Settlement records every accepted output and that identifier together to prevent payment reuse.

An agent pays over x402

Your 402 response carries the proposed Bitcoin requirements in PAYMENT-REQUIRED. The payer broadcasts, then retries with a v2 PAYMENT-SIGNATURE payload containing the original requirements and each selected output's txid and vout.

A person pays on a hosted page

The same checkout has a URL with an address, a QR code and a countdown to the rate lock. The hosted page handles the browser flow. A wallet transfer alone does not authorise access to an x402 resource.

The page is machine-readable too

Request it with Accept: application/json and it answers 402 with PAYMENT-REQUIRED, so an agent that reaches a payment link can use the x402 flow. The header carries base64-encoded JSON.

Fiat quote with a rate lock

Price in your own currency. Satsgate quotes a fixed satoshi amount. For x402, the complete payment must qualify and be recorded before expiresAt. A later exchange-rate move does not change that quote.

Satsgate tracks checkouts. An indexer supplies payment observations. For x402, the server checks the exact output total and confirmation policy, records payment acceptance, then runs the bound purchase. A balance or callback alone cannot grant access.

pending

No transaction seen at the address yet.

seen

In the mempool at 0 confirmations.

settled

Accepted under the checkout policy. For x402, the exact output set and payment identifier have been recorded before expiry; fulfil the bound purchase once.

underpaid

Arrived short. An x402 top-up must fit the output limit, bring the selected total to the exact quote and qualify before expiry.

reverted

Replaced or dropped before it settled. The checkout returns to pending and the address stays watched.

expired

The first-settlement deadline passed. Funds may still arrive, with no automatic delivery or refund under the x402 method.

These are Satsgate checkout states. The x402 settlement response has its own result and error codes. An accepted payment stays bound to one purchase even if its transaction is later replaced or reorganised out of the chain.

The x402 receipt lists every output accepted for the purchase in the bip122-payment-set extension. Keep the original requirements and payment references when retrying. A lost response is no reason to send the full amount again.

Through recoveryUntil, an authenticated retry retrieves or resumes the same purchase and returns the original receipt, even after payment expiry. A monitor may record payment first, but it must apply the same checks and share the same settlement records. The receipt confirms payment acceptance; delivery is tracked separately.

Blockonomics is the anchor indexer, with an Esplora backend alongside it. You can use your own backend to keep address monitoring under your control. For x402, the backend must establish the transaction history and fresh, consistent evidence required by the chosen confirmation policy. An unconfirmed status flag alone is insufficient.

Test mode on a simulated chain

Create a checkout, mark it seen, advance its depth, revert it. No coins, no wallet, no testnet faucet. Every failure path is reachable on demand.

Webhooks forwarded to localhost

A CLI that streams events to a local port, so you do not need a public URL to build against.

OpenAPI 3.1 for the checkout API

The product schema describes checkout requests and responses. The linked x402 proposal defines the separate payment messages and settlement rules.

An MCP server for your coding agent

Create checkouts and handle payment events. An x402 integration also validates proof, commits payment and recovers retries before fulfilling the bound purchase.

• Customers and subscriptions. Bitcoin has no pull payments, so recurring spend belongs in the payer's wallet as a standing approval rather than in our database.
• Balances and payouts, because nothing is custodial. The money is already where it is going.
• Disputes and chargebacks. Satsgate cannot undo a Bitcoin transfer. A refund needs a new merchant-authorised transaction to a separately authenticated return address.
• Platform sub-accounts.

Read the API