Hosted checkout
ATM owns checkout, Stripe Connect, payment state, receipts, and recovery while your app owns the product experience.
For apps
Payments infrastructure for Atmosphere apps.
ATM gives app builders hosted checkout, app fees, direct payments, creator approvals, products, subscriptions, tickets, native XRPC and service-auth APIs, signed webhooks, and an operator dashboard without forcing every app to become its own payment processor.
App fees and direct selling
Earn a transparent app fee for originated payments, or sell your own subscriptions, products, tickets, and services.
Native XRPC + service-auth
Call ATM the AT Protocol way: signed service-auth over XRPC for checkout, recipient approvals, analytics, segments, catalog links, and refunds.
Events, webhook or XRPC
Receive launch events as signed webhooks with retries, logs, and test events — no receiver to build — or opt into XRPC receiver callbacks once you run one.
Test and live environments
Separate setup, modules, webhook URLs, secrets, and logs so app teams can test without touching live money.
Protocol-shaped receipts
ATM keeps attested.network records strict while app-specific commerce context stays in ATM-owned contracts.
How it fits together
Originate over XRPC. ATM handles the money work.
Your app calls ATM the AT Protocol way — XRPC procedures signed with app service-auth — to start checkout for a creator or for its own products. ATM processes the payment, records it, routes app fees and payouts, then notifies your app to fulfill on the channel you choose: a signed webhook, or an XRPC receiver callback to your own service.
Your appOriginates over XRPC
ATMProcesses & records
Event back to youWebhook or XRPC receiver
Durable delivery
Every event signed, retried, and logged — webhook or XRPC.
ATM-to-app callbacks are signed HTTP webhooks with bounded retries, per-environment secrets, and an inspectable delivery log — no receiver service required. Apps without an endpoint yet still queue events durably and can redrive once a URL is added. Already running an XRPC service? Publish a receiver in your DID document and ATM delivers the same durable events as service-auth XRPC callbacks instead.
Developer-facing dashboard
ATM exposes the boring, critical surfaces apps need.
App developers need environment config, module status, app fee accounting, approval state, event delivery, and reconciliation. ATM keeps those concepts visible without leaking them into creator or payer dashboards.
Durable app contracts
XRPC and service-auth first, webhooks for universal delivery.
App-to-ATM calls are AT-native: signed service-auth over XRPC for checkout, recipient approval, event listing, analytics, segments, catalog links, and refunds. For events coming back the other way, signed webhooks are the universal baseline — zero receiver infrastructure — and apps already running an XRPC service can opt into receiver callbacks. Live subscription streams come later.
{
"type": "payment.completed",
"environment": "test",
"app": "did:plc:mcsqdltevtjpu26xthzzmm2l",
"payment": {
"amount": "24.00",
"currency": "usd"
}
}
Build with ATM
Start with the developer docs, then wire a test app.
The docs cover app registration, checkout initiation, service-auth, webhooks, event types, SDK helpers, and test/live environments.