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, earn a revenue share of ATM's application fee, 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 revenue shares or direct payments.

ATM may open your app's payment account for receiving transfers only. Where ATM supports adding merchant capabilities to that account, and after the required processor checks and onboarding, ATM may add those capabilities when your app begins selling its own products, subscriptions, tickets, or services, with the processor's merchant responsibilities set then, and the Recipient Terms apply to those sales from that point.

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, direct a revenue share 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.

The application fee ATM charges on a payment your app originates is ATM's own platform fee. ATM charges it to the recipient at the rate your app posts and the recipient accepts, subject to ATM's maximum, and, where ATM supports the processing-and-settlement charge, subject to the separately accepted cap described in section 4. ATM pays your app a revenue share of that fee under section 4. Your posted rate is an instruction to ATM about ATM's fee; it does not create a payment obligation between the recipient and your app, and you must not represent the application fee as a charge by your app to the recipient.

Apps must not hide fees, manipulate fee calculations, create misleading app-fee arrangements, or use app fees or revenue shares to operate an unsupported payment facilitator, marketplace, money transmission, stored-value, lending, or other regulated service.

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

4. Revenue share and payouts

This section governs what ATM owes your app. ATM charges the application fee to the recipient as ATM's own platform fee and, in exchange for the origination, integration, and support services your app provides, pays your app a revenue share of the application fee ATM actually collects on payments your app originated. Where ATM processes a payment on a route that collects no separate application fee, ATM uses the equivalent platform-fee amount ATM determines for that payment under the same posted rate as the revenue-share calculation base, and the rest of this section applies to it unchanged. In this section, the application fee actually collected or that equivalent platform-fee amount, as applicable, is the fee base. That revenue share is ATM's own contractual obligation to you. ATM holds no amount in trust or escrow for your app, your app has no ownership or beneficial interest in ATM's balances or in any recipient's balances, and ATM does not act as your app's agent in collecting the application fee.

Your app posts the rate for its role, at or below the maximum ATM configures, and the recipient accepts it. Under the legacy private approval flow, an app may lower a recipient's rate without a new approval; where ATM supports public root agreement records, a lower applied rate requires a newly authored public acceptance or a new addressed offer and acceptance. Where ATM has enabled the revised no-contribution fee policy, and before any refund, reversal, delegated allocation, withholding, or set-off described below, an independent app's revenue share equals the fee base excluding any separately collected processing-and-settlement charge. Earlier frozen payment authorities retain their recorded split; same-entity allocations remain internal. ATM freezes the applicable fee rate and, where the supported flow charges a processing-and-settlement amount, its separately accepted cap as part of the fee authority for each payment when that payment is prepared, so a later change to either does not alter a payment, renewal cycle, or pledge conversion whose authority is already frozen and never increases a rate or cap a recipient already accepted.

Where ATM supports the processing-and-settlement charge, the recipient may be charged only pool-level costs of settling or converting the application fee received by ATM: multi-currency settlement and inbound application-fee conversion. These components use the processor's published rate in force for the payment and the supported settlement-currency path, are allocated once among the applicable root fee pools, and never exceed the recipient's accepted cap of at most 1.5% of the applicable root fee pool. The charge is collected inside the application fee and is excluded from your revenue share. ATM returns any identified over-collection to the recipient; a shortfall is ATM's. Any excess above the accepted cap is borne under the frozen beneficiary cost policy. Separately, every cross-border transfer fee and currency-conversion cost on the transfer paying your app is your app's own cost, calculated on its actual transfer under the accepted cost policy and deducted from its revenue share. ATM restores any over-collected beneficiary deduction to that beneficiary's obligation. ATM uses the pool currency where your account can hold it, and a converting transfer requires binding processor fee authority before its allocation is frozen. Components already incurred remain subject to their accepted refund policy.

ATM calculates the fee base for each payment or renewal cycle in ATM's settlement currency. For an application-fee route, the fee base is the application fee ATM actually collected; for a route with no separate application fee, it is the equivalent platform-fee amount determined under the same posted rate. A refund or reversal of the principal fee-pool component reduces the corresponding revenue share under the allocation and refund policy frozen for that payment or cycle. Returning a separately collected processing-and-settlement charge does not reduce the principal fee-pool component or an app's unchanged revenue share. A returned beneficiary-borne deduction restores that beneficiary's revenue-share obligation. Currency conversion follows the processor's rates. No interest accrues while a revenue-share obligation to your app remains unpaid.

ATM pays live revenue shares only by transfer to your app's own verified payment account for the live environment, subject to the currently published payout policy and, where ATM has enabled occurrence-specific balance-transaction availability checks, only after those checks confirm availability in the settlement currency, and only where a supported transfer route exists between ATM's platform account and your app's account country. Verification is a precondition of live origination, not a step your app completes afterwards: ATM does not promote your app to live origination until its payment account is verified, and no revenue share accrues on live payments before that. If a verified account later loses its payout capability, is replaced, or is otherwise unable to receive a transfer, ATM defers payment of revenue-share obligations already accrued until your app restores a verified account; the same applies to any valid legacy live share recorded before this eligibility control took effect. Where ATM has enabled corridor-aware fee suppression and no supported transfer route exists for your app's account country, your app may still register and originate supported checkouts. Selling its own products separately requires eligibility for merchant services in the applicable country and completion of the supported processor onboarding and capability requirements. For new payments covered by the fee-suppression policy, no revenue share accrues for your app's role and ATM does not charge the recipient that application fee; ATM tells your app so before any recipient accepts a rate for it. Loss of a supported route does not erase obligations already accrued or later restored by a correction; those remain subject to the payment, set-off and closure provisions of these terms. Sandbox and test entries are simulations and do not create a real-money revenue-share obligation or payout. Payment is subject to the payout schedule and hold policy ATM publishes in its developer documentation, including the go-live ramp floor, any longer schedule you configure, and any risk-based extension ATM applies. A hold exists to cover refund, dispute, chargeback, and reversal exposure on the payments the share came from; it has the defined release that policy states, and ATM never holds a share without a stated purpose or beyond the maximum that policy states. ATM may delay a payout while a refund, dispute, chargeback, investigation, or compliance review affecting the underlying payment is open, and, where ATM has enabled the revised cross-border dispute policy, an undisbursed cross-border share is held on dispute open, while a released share is not reversed unless the dispute is lost.

Refunds, disputes, chargebacks, reversals, and processor adjustments recompute the revenue share for the affected payment or cycle under its frozen allocation policy. A later correction may restore an amount previously recovered; where ATM supports that correction, it records the restored amount as an unpaid obligation, applies any authorized set-off, and settles the remainder through the ordinary payout or closure policy. No additional earnings are required to preserve that obligation. Where ATM has already paid a revenue share that is later reduced or extinguished, ATM may reverse the transfer, withhold the amount from current or future revenue shares, or invoice your app for it, and you must repay any balance that cannot be recovered by set-off. ATM may apply set-off across your app's environments and across amounts otherwise owed to your app under these terms. Where ATM has enabled proportional recovery, it first reduces any undisbursed share, reverses only the released remainder, and never reverses more than was paid for that occurrence; otherwise the currently published recovery policy applies.

Where ATM supports delegated beneficiaries, your app may post an offer under which ATM reduces the revenue share it would otherwise owe your app and assumes a corresponding direct payment obligation to another registered participant for a referral, distribution, wholesale, or infrastructure role once that participant accepts. A delegated allocation never increases the recipient's cost. ATM pays each delegated beneficiary directly under ATM's own terms with that beneficiary; ATM does not forward, hold, or transmit your app's funds to it, and your app has no claim to any amount ATM owes it. Every delegated beneficiary must be a registered participant that has accepted these terms, holds a verified payment account, and has provided the tax documentation ATM requires. ATM retains a network tariff from each delegated allocation, a uniform ten percent (1,000 basis points) of that allocation under the schedule ATM publishes as atm-network-tariff-v1, and pays the beneficiary the remainder after other deductions authorized under these terms and the frozen cost policy. The tariff is ATM's fee for coordinating, attributing, and settling a sale that no single app performed; it is zero when the beneficiary and ATM are the same economic principal; it is never applied to the revenue share ATM owes your app for payments your app originates directly for a recipient; and the beneficiary acknowledges the tariff schedule assigned when its acceptance is admitted, so a later tariff change reaches only agreements accepted after the change. Separately accepted processing, transfer and conversion deductions can also reduce the beneficiary's net proceeds. A cost attributable to a delegated beneficiary is deducted inside that beneficiary's parent pool and does not increase the recipient's charge. ATM freezes the applicable cost policy and its acceptance evidence with the payment or cycle. ATM may limit the depth of delegation and the number of beneficiaries on a payment.

Where ATM supports agreement records during beta, both direct and delegated offers and acceptances are public records in their authors' Atmosphere repositories. They identify the parties and disclose their rates, roles, funding relationships, and accepted cost policies. Authoring or accepting an agreement after its publication disclosure authorizes these public records under the permissions you grant. ATM publishes corresponding settlement records showing the commissionable basis, allocations, delegated amounts, tariffs, normalized cost deductions and returns, and the full history of later corrections, including refund or dispute adjustments. These facts can reveal commercial information beyond the payment receipt. The public beta does not offer a separate private-terms or commitment-only settlement option. Previously private approvals are not published retroactively. Settlement details are public during beta; future payments may support private settlement records. ATM keeps the allocation amounts, applicable terms and correction history available to the parties entitled to them so they can check ATM's settlement calculations. Only after Spaces becomes generally available and ATM completes a reviewed integration may new payments and renewal cycles use private settlement records accessible to the appropriate parties. Corrections to earlier public settlement records remain public. Later private placement cannot make public beta records or copies already held by others private. ATM executes agreement records as instructions about the application fee ATM charges and the revenue share ATM owes; they do not create a payment obligation between a recipient and your app.

Your app is responsible for its own taxes on revenue shares it receives. ATM may require tax documentation before paying any revenue share, may withhold where law requires, and will issue information returns where law requires. Amounts stated in these terms and in ATM's dashboards are exclusive of any tax your app must account for in its own jurisdiction.

ATM makes distribution records available to your app through the dashboard and the app API, showing each planned, scheduled, held, transferred, and reversed amount. Those records are the statement of what ATM owes and has paid, and your app may rely on them for its own invoicing and accounting where its jurisdiction permits. You must notify ATM of any disputed amount within 90 days of the record appearing.

If ATM suspends or terminates your app, ATM pays live revenue shares accrued before termination after the applicable refund, dispute, and clawback windows close, subject to set-off and to any amount lawfully withheld. Where ATM cannot pay an accrued revenue share because it arose from a valid legacy live payment before verification, because your app later lost verification, because your app is unreachable, or because your app has not provided required tax documentation, ATM records the amount as an unpaid obligation and handles it under applicable unclaimed-property law. ATM does not forfeit an accrued revenue share for non-payment of a fee or for termination alone.

ATM and your app are independent contractors. Nothing in these terms creates a partnership, joint venture, employment, franchise, agency, or fiduciary relationship, and neither party may bind the other. Your app may not assign its right to a revenue share without ATM's written consent.

5. 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.

6. 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.

ATM checkout exclusively coordinates and writes payer-owned public payment records. Apps may provide checkout identity evidence but must not request payer-record bytes, write or register payer receipts, borrow or forward payer OAuth credentials, or treat a payer DID hint, standing grant, or app account association as per-payment publication 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.

7. 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.

8. 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.

9. 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.

10. 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.