HTTP-native payments for the agent economy

Current phase#

The product overview places Payway in Phase 0 — foundations.

The public interfaces are therefore explicit previews unless a backend URL or contract is actually configured.

Who it serves#

Payment lifecycle#

1. Discovery. The merchant publishes a 402 Payment Required response with price and accepted tokens. Payway operates the Bazaar listing.
2. Signing. The payer signs authorization for an exact token, exact amount, exact merchant, and limited time window.
3. Verification. The merchant sends the authorization to /verify. Payway checks signature, balance, allow-list status, and swap parameters when relevant.
4. Settlement. The merchant calls /settle. Payway broadcasts, pays gas, and returns the transaction hash.

CLIENT       GET /resource
MERCHANT     402 Payment Required
PAYER        sign exact authorization
MERCHANT     POST /verify
MERCHANT     POST /settle
PAYWAY       broadcast + pay gas
CHAIN        payer → merchant
MERCHANT     return paid resource

Facilitator endpoints#

The backend overview does not specify hostnames, payload fields, response schemas, or authentication, so this documentation intentionally stops at endpoint responsibility.

Four payment scenarios#

Fee rules#

Fee-bearing routes combine two components: a 10 bps service fee and a 5 bps insurance fee. USDG and USDC same-token settlement is free.

The overview describes staking as reducing the 10 bps merchant service component. It does not say that the 5 bps insurance component is discounted.

Atomic cross-token settlement#

The payer authorizes token A. One transaction pulls token A, swaps through Uniswap v3, checks the merchant’s minimum output, and sends token B directly to the merchant. If the minimum cannot be met, the entire transaction reverts and nothing moves.

Client journey#

Ana’s client receives a 402, selects an allowed asset from the agent wallet, signs, retries the request, and receives the paid response after merchant verification and settlement.

pip install x402-client

The overview mentions an npm option but does not give its package name, so none is fabricated here.

Merchant middleware#

Marcus adds one middleware layer, defines a price and preferred settlement token, and lets the merchant server call Payway.

cargo add x402-axum

@payway/express

FastAPI, Hono, Next.js, Fastify, and MCP are named integration surfaces. No package name or API signature beyond the two examples above is specified.

Merchant onboarding#

The five-step builder covers direct recipient, payment rule, middleware handoff, Bazaar preference, and the optional service-fee tier. It never claims to publish or stake without configured backend and contract addresses.

Bazaar discovery#

The Bazaar lets agents find a paid resource and inspect its price, accepted tokens, and settlement preference before signing. The Bazaar surface supports search and “any curated token” filtering, but stays empty until a real listing source exists.

Merchant analytics#

The merchant dashboard requires revenue over time, per-endpoint volume, per-payer breakdown, and fee analysis. A stake-tier savings message may be computed only from real merchant fees, never from a fabricated month.

Analyzer gate#

A curator proposal is not accepted until at least two of five automated static-analysis oracles attest PAYABLE. The stated purpose is catching more than 90% of known honeypot patterns before a bond can enter trial.

Trial and challenge market#

1. The curator posts at least 10,000 $PAY.
2. The token enters a 30-day trial with the curator bond fully at risk.
3. Any wallet may post a smaller challenge bond alleging fraud.
4. If the curator does not defend, the curator bond is slashed.
5. If the curator defends, the challenger has three days to escalate.

Named evidence categories include honeypot behavior, mint attacks, blacklist activation, and malicious upgrades.

Bonded committee#

An escalated dispute goes to a bonded five-person committee. The overview does not provide member selection, exact vote mechanics, or bond amounts. It does state one safety invariant: a seven-day deadlock defaults to slash.

Slash and insurance routing#

An upheld challenge removes the token and routes the 10,000 $PAY launch bond as follows:

Affected merchants file claims against the token-specific pool and receive reimbursement in $PAY. The overview does not specify claim adjudication fields or payout caps.

Why $PAY exists#

The overview specifies a fixed supply of 1 billion $PAY, no emissions, and no future minting. $PAY remains a provisional name and ticker.

Fee routing#

Fee-bearing settlements create the protocol’s distribution flow:

The overview describes fees being automatically converted into $PAY through Uniswap. Free stablecoin same-token routes do not generate a settlement fee.

Stake and unstake#

Stake $PAY in the sPAY vault, choose manual claim or auto-compound, and receive weekly fee-funded distributions. Unstaking enters a 14-day unbonding queue. Use “protocol fee distribution,” not guaranteed yield or emissions APY.

The staking surface models the queue without inventing a share price or connected contract.

Governance#

$PAY participants vote on fee rates and splits, bond size, service parameters, treasury deployment, and expansion to new chains. Priya may also delegate her stake to another participant. Thresholds, quorum, voting duration, and contract addresses are not specified in the overview.

Public dashboard data#

The public dashboard remains blank until PAYWAY_TELEMETRY_URL points at the real dashboard API.

Launch phases#

1. Phase 0 · Foundations. Testnet facilitator, pre-audit contracts, site, audit booking, legal review.
2. Phase 1 · Public testnet. Docs, live testnet playground, friendly merchants, bug bounty.
3. Phase 2 · Mainnet soft launch. USDG and USDC only; no $PAY or curator layer.
4. Phase 3 · $PAY launch. Airdrop, liquidity, staking, governance, CuratorRegistry.
5. Phase 4 · Full agent economy. Cross-token swaps, Bazaar, full curator market, then a second chain based on demand.

Competitive positioning#

These comparisons reproduce the backend overview’s product positioning; they are not presented as a live third-party service audit.

Product and messaging boundaries#

• Never describe Payway as the only x402 facilitator; the claim is Robinhood-specific and arbitrary-token-specific.
• Never imply custody. Payments settle payer to merchant.
• Never claim all fraud can be prevented.
• Never use guaranteed-return, APY, moon, or price-projection language.
• Never portray cross-token, curation, staking, governance, or Bazaar as mainnet-live before their launch phase.
• Payway is chain-agnostic in architecture but Robinhood Chain is the first beachhead.

Frequently asked questions#

Is my money safe with Payway?

Payway never holds it. The service verifies, broadcasts, and pays gas; settlement is direct.

Do I need $PAY to pay?

No. $PAY is for curator bonds, merchant tiers, protocol fee distribution, and governance.

What if a scam token is listed?

Anyone may challenge. An upheld slash sends 60% to the token’s InsurancePool, 30% to the challenger, and burns 10%.

How is this different from Uniswap?

Uniswap swaps. Payway coordinates an HTTP payment requirement, authorization, verification, gas, and settlement; it may use Uniswap inside a Phase 4 cross-token route.

What stops a copy?

The technical protocol is open. The claimed moat is the two-sided network of bonded curators and merchants relying on its allow-list.