Turn a funded wallet into a buyer for private APIs, yield plans, and paid agent actions. Pylon handles x402 challenge verification, settlement, routing, and the ledger.
The buyer uses an OWS-compatible wallet flow, but the seller never has to expose native x402. Pylon is the gateway in the middle.
Agents fetch the machine-readable catalog URL and inspect live managed-adapter services with transparent pricing.
The first request returns `402 Payment Required` with the `PAYMENT-REQUIRED` header and the exact price for the route.
The agent retries with `PAYMENT-SIGNATURE`, Pylon verifies and settles, then forwards to the private adapter.
The adapter calls the upstream provider, Pylon writes the ledger row, and the agent gets a clean response plus `PAYMENT-RESPONSE`.
If the buyer is Claude, Codex, Cursor, or another agent, it should not treat `invoke_url` as a free GET URL. The buyer should use the installed OWS wallet, pay on Base in USDC, send the exact JSON body shown in `request_example`, and let OWS handle the `402 Payment Required` retry.
Use an installed OWS wallet to handle the x402 payment flow before retrying the paid request.
The catalog is fetched live from `/.well-known/pylon-catalog.json`. It lists the current paid services from multiple upstream providers, plus pricing, examples, and x402 metadata without hardcoding a single brand.
Milestone one ships `managed_adapter` only: the seller keeps their private upstream behind a narrow adapter, and Pylon handles payment, routing, and the public surface.
The seller's upstream API stays private. Pylon only talks to the adapter, never directly to the upstream provider.
Curated adapter services map public slugs to internal routes, timeout budgets, and auth modes without exposing arbitrary onboarding yet.
Each paid request splits cleanly into buyer charge, seller payout, and a visible platform fee. The ledger records every settlement outcome.
Today the onboarding path is curated, not self-serve. A publisher adds a private adapter route, registers a public service blueprint, sets provider env vars, and redeploys. The buyer still sees one clean x402 endpoint.
Create one narrow route in your adapter app that calls the upstream provider with your secret API key and normalizes the response shape.
Add a provider blueprint plus one service blueprint with the public slug, request example, response example, pricing, and the internal adapter route.
Put upstream credentials in Railway variables for the adapter service. Do not commit API keys to the repo, and do not expose the upstream base URL to buyers.
Redeploy the adapter and `pylon-app`, confirm the new slug appears in the live catalog, then run one unpaid `curl` and one paid `ows pay request` smoke test.
`apps/<provider>-adapter/src/app.js`
`packages/config/src/index.js`
`/.well-known/pylon-catalog.json` plus `ows pay request` against `/v1/<service-slug>`
railway variables set PROVIDER_API_KEY=*** --service <provider>-adapter
railway up -s <provider>-adapter
railway up -s pylon-app
curl https://pylon-app-production.up.railway.app/.well-known/pylon-catalog.json | jq
ows pay request --wallet <ows-wallet-name> --method POST --body '<json-from-request_example>' https://pylon-app-production.up.railway.app/v1/<service-slug>Get started
Copy the catalog URL, hand it to Claude, Codex, or Cursor, and let the agent discover the paid services that Pylon monetizes and forwards.