Core concepts
The roles, records, and private boundaries behind an ATM integration.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Roles
ATM accounts are DID-based and roles are additive. The same Atmosphere account can be a payer, creator, app, and future role without losing its payment history.
- Payer
- A user who sends payments, manages subscriptions, and views purchases.
- Creator
- A user or project that receives payments through a connected payment account.
- App
- A registered DID that originates checkouts, receives events, and configures modules.
- Broker
- The service that processes payment and writes or observes proof records. ATM is the broker for ATM checkout.
Public versus private data
ATM uses AT Protocol records for portable public facts and private tables for processor, fulfillment, and customer data. This is the line to keep in mind:
- Public
- Catalog refs, product identity, price shape, settled payment amounts, proof CIDs, and safe entitlement strongRefs.
- Private
- Emails, addresses, attendee answers, webhook logs, Stripe ids, QR secrets, checkout sessions, and fulfillment state.
Payment truth
The user-facing ATM ledger only shows payments that actually occur. In-flight checkout attempts live in the private checkout session layer. Subscriptions are durable relationships, while individual invoice payments appear in the payments ledger as they settle.
Proof model
ATM understands attested.network records for one-time, recurring, scheduled, and proof records. For ATM-processed payments, ATM writes the broker proof and coordinates payer records depending on available grants and app delegation. Creator proof slots stay visible as sync tasks until the creator explicitly syncs from the ATM dashboard with the needed OAuth grant.