App Developer Terms

1. Who these terms apply to

These App Developer Terms apply when you register, operate, or integrate an app with ATM. They supplement ATM’s Terms of Service, Recipient Terms, Ticket Terms, Acceptable Use Policy, docs, dashboard settings, and any written agreement with ATM. ATM’s Privacy Policy describes ATM’s data-processing practices and does not replace any data obligations the app has to its own users.

An app may originate checkout, receive app fees, fulfill products, provide ticketing or event UX, receive webhooks or XRPC callbacks, use service-auth, and display ATM payment state. The app operator remains responsible for its own app, users, content, support, privacy notices, security, and compliance.

2. App registration and authority

You must register accurate app information, including the app DID, app URL, contact information, modules, test/live environment settings, webhook or XRPC receiver settings, and any payment-account setup needed for app fees or direct payments.

You represent that you control or are authorized to act for the app DID and app business. You must not submit another app's DID, impersonate an app, route fees to the wrong app, or use ATM credentials outside the registered app.

3. Checkout and app fees

Apps may initiate ATM checkout only for supported modules, registered environments, and authorized payment flows. Apps must show accurate recipient, amount, currency, product, subscription, ticket, tax, fee, refund, and fulfillment information before sending a payer to checkout.

For recurring payments, apps must present the amount, cadence, renewal terms, cancellation method, material benefits, and any trial or promotional terms clearly before authorization. Apps must not use preselected consent, obscure recurring terms, obstruct cancellation, or treat silence as authorization. Apps must preserve ATM's checkout disclosures and must not suppress acknowledgments, reminders, cancellation links, or change notices ATM sends through the app's configured flow.

ATM does not currently allow an app to increase the amount or change the plan of an existing subscription without a separate payer-authorized flow. Apps must not work around that restriction through processor APIs, metadata, duplicate subscriptions, or misleading replacement checkout.

ATM may route an app fee or application fee to the app where configured and supported. Apps must not hide fees, manipulate fee calculations, create misleading app-fee arrangements, or use app fees to operate an unsupported payment facilitator, marketplace, money transmission, stored-value, lending, or other regulated service.

Apps that receive direct payments, app fees, or other funds may need to complete payment-account onboarding and comply with Recipient Terms and processor requirements.

4. Service-auth, webhooks, and XRPC receivers

Apps are responsible for securing service-auth keys, webhook signing secrets, XRPC receiver configuration, test/live environment separation, replay protection, idempotency, and delivery logs. Apps must verify ATM webhook signatures or ATM service-auth JWTs before fulfilling orders or changing user state.

New app registrations default to the test environment; live configuration, including the live webhook endpoint and its own signing secret, must be enabled explicitly. A webhook endpoint is optional at registration: ATM still mints signing secrets and queues events durably, holds deliveries as awaiting configuration while no endpoint is set, and may redeliver them after an endpoint is added.

ATM may provide SDKs, docs, test events, logs, redrive tools, and fixtures, but the app remains responsible for operating its own receiver infrastructure and fulfillment systems.

Apps must not replay, forge, tamper with, or forward ATM events in a way that misleads recipients, buyers, scanners, organizers, or other apps.

5. Data access and privacy

ATM may share app-scoped payment, order, subscription, ticket, refund, dispute, proof, customer, payer, attendee, and webhook information with the originating app when needed for checkout, fulfillment, support, fraud/risk handling, receipts, reporting, or proof status.

Apps may use ATM data only for the app-scoped purpose for which ATM provided it. Apps must not sell ATM data, combine it with unrelated data in a misleading way, publish private data to public AT Protocol records, or use ATM data for unrelated advertising, profiling, surveillance, or eligibility decisions without a lawful basis and clear user notice.

An app may request or delegate a payer-owned public payment record only with authority tied to that payer and payment. A payer DID hint, standing OAuth grant, or app account association alone is not per-payment consent. Apps must not claim that a broker proof identifies a payer when it does not, and must not add email, shipping, private messages, processor identifiers, or other private order data to a public payment or app record.

Apps must maintain a privacy policy and support contact appropriate for their users and must honor deletion, correction, access, and support requests where applicable. Apps must maintain reasonable security controls and notify ATM without undue delay—and, where feasible, within 72 hours—after discovering unauthorized access to ATM data or app credentials. If applicable law requires a data-processing agreement for an integration, the app must enter that agreement before relying on ATM for the relevant processing.

Apps must retain app-scoped personal data only as long as needed for disclosed fulfillment, support, accounting, fraud, legal, or contract purposes and must securely delete or de-identify it when no longer needed. ATM may require an app to return, delete, quarantine, or stop using ATM data after a security incident, policy violation, user request, or termination, subject to lawful retention duties.

6. Products, subscriptions, and tickets

Apps may use ATM catalog records, app links, products, prices, discounts, subscriptions, and tickets only according to ATM docs and enabled modules. Public protocol records are not a substitute for private fulfillment systems, inventory, attendee answers, QR secrets, or customer support records.

If the pledges module is enabled, the app must present ATM's pledge consent and management flow accurately. A saved pledge card is not a payment or public receipt. Apps must not mark a pledge paid, trigger conversion outside ATM's authorized controls, retry a terminal pledge, conceal automatic conversion, or continue conversion after cancellation, expiry, or a superseding subscription.

For tickets, apps must use ATM's hold, availability, claim, issuance, verification, and check-in flows where ATM Tickets is the inventory authority. Apps must not oversell, duplicate, bypass, or locally override scarce ticket inventory.

7. Acceptable use and processor compliance

Apps must comply with ATM's Acceptable Use Policy, processor rules, card network rules, sanctions rules, privacy laws, consumer protection laws, tax laws, and all laws that apply to the app's users, products, events, or payments.

Apps must promptly disable checkout for unsupported recipients, unlawful products, unsafe events, excessive disputes, fraudulent activity, or any activity ATM or a processor flags as restricted or prohibited.

8. Suspension and termination

ATM may limit, suspend, disable, revoke, or terminate app access, modules, credentials, fees, webhooks, XRPC receivers, ticketing, checkout, or dashboard access if ATM believes the app creates legal, fraud, processor, privacy, security, reliability, ecosystem, or user-safety risk.

After suspension or termination, ATM may continue to process refunds, disputes, chargebacks, ticket validity, records, audits, and legal or compliance obligations connected to prior app-originated payments.

9. Indemnity

The app operator will defend, indemnify, and hold harmless Atmosphere Money Inc. and its directors, officers, employees, and agents from third-party claims, damages, penalties, losses, and reasonable legal fees arising from the app, its content or products, fulfillment, taxes, privacy or security practices, infringement, unlawful conduct, breach of these App Developer Terms, or misuse of ATM credentials and data. This obligation does not apply to the extent a claim results from ATM's own breach, fraud, willful misconduct, or gross negligence.