App dashboard guide
How app developers use the ATM App dashboard to inspect app-scoped payment activity, manage revenue, and configure modules, webhooks, secrets, fees, service-auth, and delivery logs from the Developer section.
Compatible with the closed-beta ATM app APIs and versioned ATM event headers. Check atm-api-version on every webhook or XRPC receiver event.
Dashboard mental model
ATM dashboards are role contexts for one DID. The same account can be a payer, creator, app, and future role at the same time. The dashboard keeps those accounting boundaries separate so app fee revenue, direct creator revenue, and payer history do not get mixed together.
- Payer
- Payments sent, subscriptions paid, purchases, tickets owned, receipts, and guest-management recovery when the DID is acting as a buyer.
- Creator
- Payments received directly by this DID as recipient, plus payouts, tax, disputes, reports, products, tickets, and app approvals.
- App
- Activity originated by this app DID: app-scoped payments, recipients served, subscriptions, products, tickets, app fee revenue, webhooks, and developer controls.
- Settings
- Profile, role upgrades, payment setup, contact/support, and account-level preferences.
Dashboard contexts
App operators should treat originatorDid as the App dashboard boundary. Creator dashboards use recipientDid, and Payer dashboards use payerDid. Direct sales can appear in both Creator and App contexts, but they are not counted twice as app fee revenue.
| Payer | payerDid = signed-in DID. Use it for money the account has sent. |
|---|---|
| Creator | recipientDid = signed-in DID. Use it for money paid directly to this account. |
| App | originatorDid = signed-in DID. Use it for payments this app started, regardless of which creator received the money. |
| Direct sales | originatorDid = recipientDid = app DID. Show as direct revenue, not as app-fee revenue. |
| App fee revenue | Sum only the app share from app-originated payments to other recipients. |
App section map
The App dashboard has a short top-level section list. Configuration and webhook controls now live inside Developer; older links that use appSection=configureor appSection=webhooks redirect to that section.
| Overview | Readiness, setup actions, module status, payment setup, callback health, and quick links. |
|---|---|
| Payments | App-originated payment ledger with search, export, avatars, payment details, app fee, and direct revenue context. |
| Creators | Recipients served by the app. Opens app-scoped creator detail for payments, subscriptions, products, tickets, and approval state. |
| Subscriptions | Recurring relationships originated by the app. |
| Products | ATM catalog products linked to this app for fulfillment and app-specific product handoff URLs. |
| Tickets | Ticket module state: ticket activity, delivery health, QR/pass settings, and scanner management entry points. |
| Revenue & payouts | App fee revenue, direct revenue, app-fee settlements, and processor account tools for the app's own payment account. |
| Developer | App configuration, modules, payment methods, public-record policy, webhook settings, XRPC receiver config, secrets, test events, logs, redrive, service-auth, and API explorer. |
Control-to-docs map
Every technical control in the app dashboard maps to an integration contract. Use this table when reviewing the dashboard before a new app pilot.
| App overview command center | Shows gross originated volume, app fee revenue, direct revenue, recipients served, active subscriptions, ticket issuance, ticket delivery health, and setup actions. |
|---|---|
| App payments | App-scoped payment ledger with search/export, payment details, processor summaries, app fee/direct revenue, and product/order refs. |
| App creators | Recipients served by this app, approval status, payable activity, app-originated payments, subscriptions, product links, and ticket counts. |
| App revenue & payouts | Reconciliation view for app fee revenue, app-fee transfer settlements, bank payouts, and direct revenue without mixing creator-wide payments from other apps. |
| App profile and app URL | App onboarding and App dashboard guide explain the ATM profile plus app-specific URL fields. |
| Test/live environment switcher | Testing and environments explains environment isolation, secrets, modules, and live promotion. |
| Developer > App configuration | Modules, payment methods, app URL, fee policy, public-record defaults, Tickets options, and future modules. |
| Checkout payment methods | App dashboard guide explains app/environment payment method policy. ATM blocks Klarna by default and keeps wallets/Link/card/bank eligible where Stripe supports them. |
| App fee and ATM support share | App dashboard guide and Compliance boundaries describe fee ownership and platform responsibilities. |
| Developer > Webhook settings | HTTP webhook URL, XRPC receiver URL, event selection, delivery pause/resume, secret rotation, test events, logs, and redrive. |
| HTTP webhook URL | Webhooks and XRPC explains raw-body signatures, delivery ids, event filtering, retry, and redrive. |
| XRPC receiver URL | Service-auth cookbook and Webhooks and XRPC explain optional receiver callbacks and ATM service-auth verification. |
| Event subscriptions | Webhook events and Event payload examples list supported event types and payload contracts. |
| Send test event | Webhook test console and Testing package explain local receiver tests before real checkout. |
| Delivery logs and redrive | App dashboard guide and Testing cookbook explain failed/config-needed deliveries and safe replay. |
| Signing secret copy and rotation | App dashboard guide plus Security model cover current/previous secrets and rotation overlap. |
| Service-auth audience and methods | Authentication, Service-auth cookbook, and API reference document lxm/aud/iss expectations. |
| Tickets module and QR/pass settings | Developer > App configuration controls app-level Tickets settings; Tickets overview links to atmosphere.tickets for ticket-specific setup, holds, issuance, QR/pass, scanner flows, and ticket delivery QA. |
| Tax, risk, reports, disputes | Creator and App dashboard payment contexts show safe processor/account state without exposing unrelated creator or buyer data. |
App overview
The App overview is a command center for the active environment. Use it to check whether the app is ready to originate payments, whether callbacks are healthy, and whether any creator approval or receiver action is blocking fulfillment.
- Gross volume
- All successful payments where the app is the originator.
- App fee revenue
- The app share from payments originated for other recipients.
- Direct revenue
- Payments where the app also receives the money, such as its own products or subscriptions.
- Recipients served
- Creators, projects, apps, or organizers connected to this app through approvals, payments, products, subscriptions, or tickets.
- Ticket operations
- Ticket counts, QR/pass enablement, recent delivery attempts, and scanner/check-in health for app-originated ticket activity.
- Action queue
- Pending approvals, needs-review approvals, delivery failures, receiver readiness, app origin, and payment setup.
- Delivery health
- Recent webhook/XRPC receiver delivery status for the selected environment.
Creators and app visibility
The App > Creators view is a Stripe-like app-scoped operational ledger, not a creator-wide admin console. It helps an app operator reconcile activity the app originated while protecting creator and buyer data outside that app relationship.
| Visible | ATM payment id, timestamp, environment, recipient DID/profile, payment type, amount, status, app fee, product/listing refs, subscription status, ticket status, webhook state, and public proof state. |
|---|---|
| Conditional | Payer DID/handle when the buyer was signed in or public/app-visible, plus buyer contact, shipping, or ticket delivery fields only when needed for app fulfillment, receipts, support, or ticket delivery. |
| Never visible | Payments from other apps, unrelated creator Stripe/KYC/tax data, full card or bank data, unrelated customer history, raw QR/pass secrets, and creator-wide payout details. |
| Creator approval | An app must be approved by the creator for each environment, payment type scope, fee cap, and public-record policy before checkout can start. |
| Material changes | Adding payment types, increasing app fees, or making record behavior more public moves the relationship to needs review. |
App profile
The app profile uses the same ATM profile fields as any account: avatar, display name, and description. App-specific fields should be limited to app URL, modules, fees, receivers, and developer config.
- Use an app-owned DID, not a developer's personal DID.
- Set an app URL that users and operators can recognize.
- Keep payment processor ids, secrets, and webhook URLs private in ATM state.
Environments
| Test | Default for new apps. Use it for fake payments, app sandbox traffic, receiver testing, and module integration. |
|---|---|
| Live | Explicit production configuration with separate webhook URL, signing secret, event selection, and fee settings. |
| Environment switcher | Every app developer page should make the active environment obvious before saving config. |
Modules
Modules control which surfaces an app can use. Enabling a module does not make an app responsible for every user-facing feature; it grants the app access to the matching ATM contracts and dashboard tools.
| Payments | Hosted checkout, app-scoped payment visibility, receipts, refunds through ATM policy, and payment events. |
|---|---|
| Products | Catalog refs, app fulfillment links, product/update/archive events, and product purchase visibility. |
| Subscriptions | Recurring payment relationships, app subscription policy, amount changes, cancellation, and renewal events. |
| Tickets | Ticket availability, holds, free claims, issuance, QR/pass settings, ticket email delivery logs, verify, check-in, and ticket events. |
| Machine payments | Roadmap module for MPP/x402-style flows; keep disabled until the contract is tested. |
Payment methods
Each app environment has a private checkout payment-method policy. ATM resolves that policy when checkout starts, stores the snapshot on the payment row, and then asks Stripe to show only methods that are also eligible for the buyer, currency, and connected account.
| Launch default | Cards, Link, Apple Pay, Google Pay, and US bank account where eligible. |
|---|---|
| Klarna | Explicitly disabled unless ATM and the app opt into it later. |
| Wallets | Apple Pay and Google Pay ride card eligibility and may require Stripe payment method domain setup. |
| Bank | US bank account is available only for eligible USD checkouts and accounts. |
| Product overrides | Reserved for future private product/listing policy. Public catalog records do not carry payment-method settings. |
Public records
Apps can configure public app records separately from public Atmosphere payment proofs. ATM enforces the payment-proof setting; app-owned social, feed, support, or purchase records remain under the app’s control.
| App record | Whether the app intends to create a public app/social record for the transaction. |
|---|---|
| Payment proof | Whether ATM writes or requests public network.attested payment/proof records. |
| Payer choice | Whether the app presents public/private choice in its checkout UX. |
| Coupled | Whether app record and payment proof should be shown as one choice in app UX. |
Fees
Independent apps receive the app fee they configure. ATM collects that Stripe application fee first, then transfers the app share to the app’s payout account. ATM does not add a mandatory ATM fee on top. Apps may optionally share a portion of their app fee back to ATM.
- App fee
- The fee configured by the originating app for payments it starts.
- App-fees-first mode
- An app mode where ATM emphasizes app-fee revenue first while the same payment account can support direct revenue later.
- App-fee settlements
- ATM transfer rows that move the app share from ATM's application-fee pool to the app's connected account.
- Pending settlement
- A planned app-fee transfer that has not moved yet. If the app has no payout account, it waits for payout setup.
- Failed settlement
- A transfer attempt that Stripe rejected or ATM could not complete. Operators can retry it through the distribution backstop after review.
- Reversed settlement
- An app-fee transfer that was reversed because the underlying payment was refunded, disputed, or otherwise unwound.
- Direct payments
- Payments where the app is both originator and recipient, such as a premium app subscription. These can use 0 app fee.
- ATM support share
- Optional percentage of the app fee the app voluntarily shares with ATM.
- ATM-owned apps
- Apps such as Supper keep their app fee inside ATM because they share the same legal entity.
Tax, risk, and reporting
ATM stores private checkout snapshots for routing, tax liability, invoice issuer, payment method policy, allocations, and processor risk/review state. Apps see only app-scoped operational payment facts for payments they originated.
- Tax setup
- Use ATM's embedded Stripe Tax surfaces in the creator/app payment context. Private tax IDs, addresses, and registrations do not go on protocol.
- Risk and disputes
- Risk/review/dispute status can appear in dashboards and events without exposing raw processor internals.
- Reporting
- ATM keeps gross volume, app fee revenue, direct revenue, creator revenue, refunds, disputes, tax, processing fee, allocation, and settlement snapshots separate.
- Future marketplace routing
- Destination charges and separate charges/transfers remain disabled until the compliance model and processor capabilities are ready.
Developer section
Developer is the app control plane. It contains app configuration, webhook settings, webhook credentials, XRPC receiver settings, delivery tools, service-auth guidance, and the app API explorer. This keeps setup controls close together without stretching the App dashboard into separate Configure and Webhooks sections.
Webhook settings
HTTP webhooks are the default receiver path. ATM signs every delivery with the environment-specific secret and stores attempts so developers can redrive safely.
- Verify the exact raw body before parsing JSON.
- Verify `Atm-Signature` and `Atm-Delivery-Id`.
- Store delivery id before side effects.
- Return success for duplicates after confirming state.
- Use the dashboard to send test events and redrive failed deliveries.
XRPC receivers
XRPC receivers are optional and useful for AT Protocol-native apps that already expose an app service. They receive the same event envelope, but authenticate ATM with service-auth instead of HMAC.
| Best for | Apps that already host XRPC methods and want protocol-shaped callbacks. |
|---|---|
| Not required for | Simple apps, webhook-only apps, or early starter-kit integrations. |
| Verify | Issuer, audience, method NSID, expiry, signature, and replay state. |
Delivery logs and redrive
Delivery logs are the operational truth for app callbacks. Use them when a buyer paid but the app UI did not update, or when a ticket issued but the event app did not display it.
- 01
Queued
ATM has stored the event and scheduled delivery.
- 02
Delivered
Receiver returned success; app should have processed idempotently.
- 03
Failed
Receiver returned error or timed out; fix endpoint then redrive.
- 04
Config needed
No receiver URL is configured yet; add one and redrive pending deliveries.
- 05
Filtered
The app disabled this event type for the environment.
Secrets and rotation
Rotate secrets per environment. During overlap, ATM can emit multiple v1 signatures so receivers accept either current or previous secret.
- Never paste webhook secrets into browser code.
- Rotate test and live secrets independently.
- Deploy receiver support for the new secret before ending overlap.
- Use the dashboard copy state to avoid copying stale values.
Moving to live
- Test environment passes checkout, callback, redrive, and refund paths.
- Live webhook or XRPC receiver is configured separately.
- Live app fee and ATM support share are reviewed.
- Recipient payability checks are implemented before payment buttons appear.
- Support, privacy, and terms links are ready.