Payment infrastructure for autonomous commerce

Turn every API call into a transaction.

The internet taught software to call APIs. NetDollar gives those calls a safe, standard way to pay.

Start building See the protocol

x402 v2 native Exact USDC on Base Built for retries

NETDOLLAR / LIVE REQUEST00:00:184

GET

/v1/research/brief

402

PAY

amount=25000 · network=base

SETTLEMENT

0x7a4d...e91c

RESULT

DELIVERED

The payment layer for software that acts

402-nativePayment is part of the request.

DurableRetries recover the same purchase.

Edge-readyVerify and settle close to the API.

01 / The opportunity

Commerce is becoming executable.

A human checkout is a conversation. An agent needs a protocol. When payment can happen inside the request, useful APIs become reachable at the exact moment intent exists.

NetDollar gives sellers the control plane behind that moment: terms, verification, settlement, identity, and recovery in one durable purchase record.

See the operating model

02 / The protocol

One request. Four clear moments.

No new checkout. No opaque redirect. Just a standard HTTP exchange with payment made explicit.

Request

A buyer calls an API the same way it calls any other route.

GET /v1/research/brief

Challenge

The seller returns the price and payment terms as HTTP 402.

402 PAYMENT-REQUIRED

Authorize

The buyer checks policy, signs once, and retries with a payment header.

PAYMENT-SIGNATURE

Deliver

NetDollar verifies, settles, and gives the seller a durable outcome.

200 + receipt

03 / For developers

Three calls. One reliable payment rail.

Keep your API. Add an economic boundary that agents can understand and your team can operate.

01GET /v2/x402/supported

02POST /v2/x402/verify

03POST /v2/x402/settle

Read the x402 docs

seller.tstypescript

1const payment = await netdollar.pay({
2  resource: "/v1/research/brief",
3  amount: "25000", // $0.025 USDC
4  network: "base",
5});
6
7return payment.ok ? payment.data : payment.error;

04 / The operating model

Built for the part nobody wants to debug at 2 a.m.

Stable purchase identity

Every attempt belongs to a durable purchase. A timeout does not become a second debit.

Idempotent by design

Evidence you can follow

Verify, settle, and confirmation events stay connected so finance and operations see what happened.

Auditable state

Fail closed in production

Local simulation is explicit. Production requires a real facilitator and an authenticated tenant.

No silent fallback

05 / Start with your agent

Give your coding agent a better first instruction.

Copy a focused implementation brief and turn a paid route into a working integration.

Seller integration

Add a paywall to an existing API.

Add NetDollar x402 payment enforcement to my API.

Route: /v1/premium/quote
Rail: exact USDC on Base
Facilitator: https://api.staging.netdollar.dev

Return HTTP 402 with PAYMENT-REQUIRED when unpaid. On a paid retry,
validate the payment payload, call /v2/x402/verify, call /v2/x402/settle,
and only then return the protected response. Preserve the payment identifier
and make retries idempotent. Read the x402 v2 and NetDollar docs first.

Buyer integration

Let an agent pay within policy.

Build a typed buyer helper for a paid API.

Handle the HTTP 402 challenge, validate amount/network/asset/payTo against
local policy, sign the payment, retry with PAYMENT-SIGNATURE, and return a
typed result. Enforce a daily spend cap, use a stable payment identifier,
and never sign a request outside the allowlist. Use the NetDollar staging
facilitator while testing.

Questions, answered

The short version.

What is NetDollar?

NetDollar is a payment facilitator for machine-native commerce. It gives API sellers a standard way to price a request, accept a signed payment, and receive a durable settlement outcome without building the rail themselves.

Does this replace our API or billing system?

No. NetDollar sits at the payment boundary. Your API stays yours, while payment terms, verification, settlement, and recovery become a protocol step in the request.

What can we test today?

Start on the staging facilitator with exact USDC on Base. Use a low-value testnet flow, confirm the 402 challenge and paid retry, then move to production only after provider, tenant, and operational checks are complete.

What happens when a request times out?

The purchase keeps a stable identity and journal. A retry can recover the original outcome instead of silently creating a second payment. Uncertain provider results remain visible for reconciliation.

The rail is open.

Give your API a way to say yes.

Start building