App dashboard guide
How app developers use the ATM App dashboard to inspect app-scoped payment activity and use Developer settings for modules, ticketing, webhooks, secrets, fees, service-auth, and delivery logs.
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. |
Earn app-context section map
App-role accounts use the Earn dashboard with earnContext=app for app-scoped operational activity. Configuration and webhook controls live in Settings → Developer. Legacy section URLs (transactions, revenue, payouts, reports) keep resolving to the sections below for compatibility.
| Home | Readiness, setup actions, module status, payment setup, callback health, and quick links. |
|---|---|
| Income | App income view: consolidated app-fee and direct-revenue metrics, app-fee settlement rows, and the processor direct-charges browser. Disputes for direct app payments live under Income as a sub-tab. |
| Transactions | The ATM-generated payment ledger: search, export, avatars, payment details, app-fee and direct-revenue context. |
| Balances | Processor balances, payout options and schedule, instant payouts, payout history, and test payment setup for the app's own payment account. |
| Reporting | Processor balance and payout-reconciliation reports for the app's own payment account. |
| Creators | Recipients served by the app. Opens app-scoped creator detail for payments, subscriptions, products, tickets, and approval state. |
| Customers | Payers and guests who bought through the app. Opens app-scoped customer detail for payments, purchases, subscriptions, and tickets. |
| Subscriptions | Recurring relationships originated by the app. |
| Products | ATM catalog products linked to this app for fulfillment and app-specific product handoff URLs. |
| App-owned products | Products, plans, memberships, services, or ticketed offers where the app is the merchant/owner. |
| Tickets | App-originated ticket activity: issued tickets, organizers, delivery failures, check-in state, payment links, and buyer/customer links. |
| Settings → Developer | Setup, Webhooks, Ticketing, Tools, and Reference panes for configuration, delivery, secrets, test events, logs, 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.
| Earn Home, app context | Shows gross originated volume, app fee revenue, direct revenue, recipients served, active subscriptions, ticket issuance, ticket delivery health, and setup actions. |
|---|---|
| Earn Income, app context | Consolidated app-fee + direct-revenue view with settlement rows and the processor charge browser; disputes for direct app payments are an Income sub-tab. |
| Earn Transactions, app context | App-scoped payment ledger with search/export, payment details, processor summaries, app fee/direct revenue, and product/order refs. |
| Earn Creators, app context | Recipients served by this app, approval status, payable activity, app-originated payments, subscriptions, product links, and ticket counts. |
| Earn Balances + Reporting, app context | Processor balances and bank payouts under Balances; reconciliation reports under Reporting — for the app's own payment account, 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. |
| Settings → Developer → Setup | Modules, payment methods, app URL, fee policy, public-record defaults, 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. |
| Settings → Developer → Webhooks | 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. |
| Settings → Developer → Ticketing | Controls the Tickets module, QR/pass defaults, scanner settings, and fallback/debug ticket tools. App dashboard → Tickets stays operational: issued tickets, delivery, check-in state, and activity. |
| 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
publicRecords is the app-level policy for ATM’s public network.attested.* records. New apps default to enabled with a public broker-anchored attestation — the proof lives in ATM’s own repo and needs no third-party consent — while the app-record payload axis stays private. If a checkout sends no explicit choice, ATM applies the app’s configured per-payment-type policy; when the master switch is off, checkout still works but per-checkout overrides cannot make app-originated payments public. Payer-anchored records are gated separately and are never written without per-payment buyer authority. App-owned social, feed, purchase, review, RSVP, or other commerce-adjacent records remain under the app’s own OAuth scopes and UX.
| Enabled | Master switch, on for new apps. Off means per-checkout overrides can never make a payment public. |
|---|---|
| Attestation | Public by default: the broker-anchored attested record written to ATM's own repo. |
| App record | Private by default; a payload axis apps opt into explicitly. |
| Fallback | No checkout-level choice means the app's configured per-payment-type policy applies. |
| App-owned records | Outside ATM policy; controlled by the app's own OAuth scopes and product 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.