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, Privacy Policy, Recipient Terms, Ticket Terms, Acceptable Use Policy, docs, dashboard settings, and any written agreement with ATM.

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.

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.

Apps must maintain a privacy policy and support contact appropriate for their users and must honor deletion, correction, access, and support requests where applicable.

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.

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.