Privacy Policy

This policy explains how Zuuppa Inc., a Delaware corporation (“Zuuppa”, “we”, “us”), handles personal data. It took effect on 16 August 2026 and it covers this website, the dashboard, the mobile app, the API and the SDKs. It forms part of our Terms of Service.

It covers two groups of people, treated very differently:

• Merchants: people who request access, hold an account and use the API. We decide how their data is handled, and most of this policy is about them.
• Buyers: people who pay a merchant through Zuuppa. Buyers have no account with us. We hold whatever the merchant's checkout collected, on that merchant's instructions, and If you're a buyer, read this is written for them.

Data protection law distinguishes the party that decides why data is collected (a “controller”) from the party that handles it on the first party's instructions (a “processor”). Zuuppa is both, depending on whose data it is.

Merchant data: we are the controller

Your account, your configuration, your support requests, your access request and how you use the Service. We decide what to collect and why, and this policy is our notice to you.

Buyer data: we are the processor, you are the controller

A buyer's name, email or postal address reaches us only because the merchant's checkout asked for it. There is no Zuuppa-hosted checkout page: the checkout is the merchant's own app with our SDK in it, and every one of those fields is disabled unless the merchant turns it on. The merchant decides what to collect and why; we store it against the payment and use it only to provide the Service.

Payment records: we are the controller

Addresses, amounts, assets, statuses and on-chain signatures are generated by the Service itself. We hold them as controller, because we need them to run and account for the Service whatever the merchant decides.

The practical consequence, for a buyer: if you want your details corrected or deleted, ask the merchant you paid. They instruct us, and we act on their instruction. We'll help them, but we can't decide it for them.

We don't yet offer a data processing agreement with standard contractual clauses to merchants who need one. That's a real gap, it's on the list in Changes and pre-launch commitments, and if your compliance position needs one now, write to us.

When you request access

The access-request form asks for your email and your name, and optionally your company, website, what you're building, and your expected monthly volume. We also record the IP address the form was submitted from, and a flag if the submission tripped our bot trap. We use all of it to decide whether to invite you and to get in touch. Submitting the form does not create an account.

When you have an account

• Your email address and, if you added one, your phone number. These are how you sign in. They are held by our authentication provider rather than in our own database, which is why we never hold a password of yours.
• Your account configuration: your business name, your destination wallet address, the assets you accept, your webhook endpoint, and your item catalogue.
• API key metadata: when a key was created, when it was last used, and when it was revoked. Keys themselves are stored hashed, so we cannot show you a key again after you first see it.
• Support requests you send from the dashboard, with your account id and your contact email or phone attached automatically.
• If you use the mobile app and enable notifications, your device's push token.
• Aggregate statistics about your account's activity: daily volumes, counts, and a count of distinct buyer email addresses where your checkout collected them.

If a merchant's checkout collects buyer details, we store them attached to that payment. The fields the SDK can collect are:

• first name and last name;
• email address;
• a postal address: country, two address lines, city, state or region, and postal code.

Every one of those fields is off unless the merchant turns it on, so what we hold about a particular buyer depends entirely on the merchant they paid. The details are submitted directly from the checkout to us using a secret scoped to that single payment, stored on the payment record, and indexed so the merchant can search their own payments by name or email. We also count distinct buyer email addresses to produce a merchant's statistics.

We use buyer details only to provide the Service to the merchant: showing the merchant their own order, letting them search it, supporting them, and producing their reports. We do not use buyer details for our own purposes, we do not build a profile of any buyer across merchants, and we do not contact buyers.

Buyer details are not included in the webhook events we send to a merchant's server; a merchant reads them through the authenticated API instead. Beyond buyer details, every payment also produces the record described in Payment records, which exists whether or not any details were collected.

Using the Service produces records we keep. For each payment:

• the amount, the asset, and the USD price it was quoted at;
• the deposit address we derived, the destination address it settled to, and for a return, the address the funds came from;
• the on-chain transaction signatures;
• every status transition and its timing, including failures and retries;
• our fee and the network fee;
• the items in the order, if the merchant used our catalogue;
• the reference and metadata the merchant attached (see the warning below);
• each webhook delivery attempt and the response it got, so a failure can be retried and explained.

Our API server writes runtime logs (timestamps, request paths, status codes, durations and error detail) used to run the Service, investigate incidents and debug. They are held by our hosting provider.

IP addresses. There is exactly one place in the product where we store an IP address: the access-request form. We keep the IP a request was submitted from and use it for one purpose, rate-limiting that form to five submissions per IP address per hour. We don't store an IP address against your account, your sessions or your payments, and we don't store a user-agent string anywhere.

Our website and dashboard are served through a hosting provider that sees your IP address and request metadata as part of delivering pages to you, as any web host does. When we report an error to our error-monitoring provider, that report carries payment context including the payment's reference and, for a return, the sending address.

• No advertising or analytics trackers, anywhere on this site, in the dashboard or in the app. No pixels, no session recording, no A/B testing tools, no third-party fonts. This is why there is no cookie consent banner: there is nothing to consent to.
• No profiling, no cross-site tracking and no data bought about you from anyone else.
• No identity documents and no KYC data. We don't verify merchant identity, so we hold nothing to verify it with.
• No passwords. Sign-in is a one-time code through our authentication provider.
• No card numbers or bank details. There is no card rail in this product.
• No private keys of yours. The keys to your destination wallet never leave your possession, though note that we do hold the keys to the deposit addresses funds pass through, which the terms explain at length.
• No special-category data (health, biometrics, race, religion, politics, sexuality, union membership) is asked for anywhere. Don't send it to us.
• No automated decision-making with legal or similarly significant effects. A human decides whether to grant access.

For merchants in the EEA, the UK or Switzerland, our legal basis for each purpose is set out below. Elsewhere the purposes are the same, and the basis is your agreement to our terms.

Providing the Service

Creating payments, deriving addresses, detecting and settling funds, sending webhooks, showing you your history and your reports. Basis: performance of our contract with you.

Handling buyer details

Storing, indexing and returning the details a merchant's checkout collected. Basis: performance of our contract with the merchant. As between us and the buyer, the merchant is the controller and must have its own basis for collecting them.

Deciding on an access request

Reading your submission and getting in touch about it. Basis: our legitimate interest in choosing who we onboard during an invite-only beta, and steps taken at your request before a contract.

Keeping the Service secure and working

Rate-limiting, abuse and fraud investigation, debugging, error reporting, backups. Basis: our legitimate interest in a Service that stays up and isn't abused, which is also your interest, since your funds pass through it.

Supporting you

Answering your requests and looking at your payments alongside the question. Basis: performance of our contract.

Service messages

Telling you about a fee change, a breaking API change, an incident or a change to these documents. Basis: performance of our contract. These aren't marketing, and you can't opt out of them while you hold an account.

Push notifications

Sending an alert to your device about your own payments, if you enabled them. Basis: your consent, withdrawable in your device settings.

Accounting, tax and legal compliance

Keeping financial records and responding to lawful requests. Basis: compliance with a legal obligation.

Defending ourselves

Keeping the records we'd need to establish or defend a legal claim. Basis: our legitimate interest, and in some cases a legal obligation.

We use a small number of providers, each for one job. This is the complete list of the ones that can see personal data:

Supabase: Authentication and the primary database

Your email address and phone number, your session, and every record described in this policy

Fly.io: Hosting for the API server

All API traffic in transit, and the server's runtime logs

Cloudflare: Hosting and delivery for this website and the dashboard

Request metadata for pages you load, including your IP address

Solana RPC providers: Reading the chain and broadcasting settlement transactions

Addresses and transactions, all of which are public on-chain regardless

Helius and Jupiter: Token price data used to convert a USD price into a token amount

Which asset a price was requested for. No data about you or your buyer

Firebase Cloud Messaging (Google): Push notifications to the mobile app, if you use it

Your device push token and the notification's contents

Sentry: Error and crash reporting

Error detail with payment context attached, including the payment's reference and, for a refund, the sender's address

We don't publish a formal subprocessor list with notice of changes yet; the list above is the whole of it today, and Changes and pre-launch commitments is where that commitment lives.

Beyond those providers, we disclose personal data only:

• on your instruction, including to the webhook endpoint you configured;
• where the law requires it, after we've checked the request is valid and lawful, and we'll tell you unless we're forbidden from doing so;
• to protect against fraud, or a threat to someone's safety or to the security of the Service;
• to our professional advisers, under duties of confidence;
• to a successor if the business is sold, merged or reorganised, in which case this policy travels with the data, or you get notice before it doesn't.

When we send a webhook, we send it to the endpoint you configured, over the internet, to a server we don't control. Where it goes after that is your responsibility. Point it at a server you control, use HTTPS, and verify the signature. The same applies to anything you export or read through the API.

We do not sell personal data, and we never have. We do not share it for cross-context behavioural advertising, we do not disclose it for anyone else's marketing, and we do not use or disclose sensitive personal information for any purpose beyond providing the Service. We have no advertising business, and no plan for one.

This is the part people are most often surprised by, so it gets its own clause.

Every payment through Zuuppa is a transaction on Solana, a public blockchain. Deposit addresses, destination addresses, amounts, assets, timings and signatures are visible to anyone who looks, permanently. We cannot edit or delete them, and neither can you. Anyone who can link an address to a person can see that address's entire history, and blockchain analytics firms do exactly this for a living.

A fresh address per payment makes activity harder to link together from the outside, but it is not anonymity, and it is not anonymity from us: because every deposit address is derived from a single master key that we hold, we can associate every deposit address we ever generated with each other and with the account it belongs to. Treat your destination wallet address as public information, because it is.

No right of erasure can be exercised against a public blockchain, by us or by anyone. Your rights (EEA, UK and Switzerland) is honest about that limit rather than promising around it.

Some of our staff can reach production data using an operator credential. What that credential can do, plainly:

• read every account, every payment including any buyer details attached to it, every item, every access request including its IP address, and every support request;
• return a payment to its sender, complete a payment by hand, or move funds out of a deposit address;
• send a push notification to every device registered with the Service.

Access is limited to the people who need it to operate the Service and support merchants, and it's used for that. We'll be precise about the limit: we do not currently keep an audit log of staff access to production data. That means access is restricted but not independently verifiable after the fact. Building that log is on the list in Changes and pre-launch commitments. The operational powers above are also described, and pre-authorised, in the terms' intervention clause.

Concretely, and for as long as we hold it:

• Payment records, including any buyer details attached to them, are kept indefinitely. They are financial records, they are what we'd need to answer a question about a payment years later, and some of them we're required to keep.
• Account and configuration data is kept while your account is open, and in archived form after it closes.
• Access requests are kept indefinitely, including declined ones and their IP addresses.
• Support requests are kept indefinitely.
• Server and hosting logs are kept for as long as our hosting and error-monitoring providers keep them under their own retention settings.
• On-chain data is permanent and is not ours to delete. See the on-chain clause above.

We are committed to publishing defined retention periods for each category above, and to building the deletion job that enforces them, before general availability. Until then, if you want something deleted that we're not required to keep, ask us and we'll do it by hand; Your rights (EEA, UK and Switzerland) explains what we can and can't remove.

What we actually do:

• Encryption in transit, everywhere, for the website, the dashboard, the app and the API.
• API keys stored hashed, never in plaintext, and revocable by you at any time.
• Authentication handled by a dedicated provider using one-time codes, so we hold no passwords.
• Webhooks signed with an HMAC over the raw body, so you can verify an event came from us.
• Accounts isolated from each other at the data layer, so one merchant's credentials cannot read another's data.
• Rate limiting and a bot trap on the public form, and rate limits on the API.
• Error and crash monitoring, so failures surface to us rather than being swallowed.
• Encryption at rest and backups as provided by our database and hosting providers.

Where we fall short today, stated plainly because you're trusting us with money and are entitled to price that trust accurately:

• The keys that hold funds in flight are held by our own software, not in a hardware security module or a managed key service, and they derive from a single master key rather than being partitioned per payment or per account. That is a concentration of risk.
• The dashboard does not offer two-factor authentication yet, so the security of your account is the security of the mailbox or phone number you sign in with.
• Staff access to production data is not audit-logged, as described above.
• We have not had an external security audit or a penetration test, and we hold no security certification.
• Backups exist as our providers provide them; we have not run a documented restore test.

Each of those is on the list in Changes and pre-launch commitments. No system is perfectly secure and we won't pretend otherwise. If you think you've found a vulnerability, write to support@zuuppa.com. We'll take it seriously, we'll work with you on it, and we won't pursue anyone who reports something in good faith and doesn't exfiltrate or destroy data.

If a breach affects your personal data, we'll tell you without undue delay and, where the breach is likely to present a risk to you, within 72 hours of becoming aware of it. We'll tell you what happened, what data was involved, what it means for you, what we're doing about it, and what you should do. We'll notify regulators where the law requires it.

If the breach involves buyer data you collected, we'll give you what you need to make your own notifications: you are the controller of that data, so those notifications are yours to make.

If you're in the EEA, the UK or Switzerland, you have the right to ask us to:

• confirm what personal data we hold about you, and give you a copy;
• correct data that's wrong or incomplete;
• delete data we no longer have a basis to keep;
• give you a portable, machine-readable copy of data you gave us, or send it to someone else;
• restrict what we do with your data while a dispute about it is resolved;
• stop processing based on our legitimate interests, where you object;
• withdraw a consent you gave. Push notifications are the only thing we rely on consent for.

Write to support@zuuppa.com. No special form, and no charge for a first reasonable request. We'll respond within 30 days, and tell you if we need longer. We may ask you to confirm your identity, so we don't hand your data to someone else. There is no self-service export or deletion tool yet; building one is on our list, and until then a request means a human at our end.

Three honest limits

• We can't delete anything from the blockchain. Nobody can.
• We can't delete payment records we're required to keep for accounting or legal reasons, or that we need to establish or defend a legal claim.
• If you're a buyer, we act on the merchant's instructions for the details their checkout collected, so we'll pass your request to them rather than deciding it ourselves.

You can also complain to your local data protection authority, or to the UK Information Commissioner's Office. We'd rather you gave us a chance to fix it first, but that's your right and not a condition.

If you're a California resident, or in a US state with a comparable law, this clause is your notice at collection and your statement of rights. In the twelve months before the date at the top of this page we collected the following categories, all of them described in the clauses above:

Identifiers

Your name, email address, phone number, and (for the access-request form only) your IP address. For buyers, whatever the merchant's checkout collected: name, email, postal address.

Commercial information

Records of payments processed, the items in an order, amounts, assets and the fees charged.

Internet or network activity

Server and hosting logs: request paths, status codes, timings and error detail. No browsing history, and no tracking across sites.

Professional or employment information

Your company, your website and what you're building, if you gave them on the access-request form.

Financial information

Blockchain addresses and transaction records. No card numbers and no bank details; there is no card rail in this product.

Inferences

None. We don't build profiles.

Sensitive personal information

None collected, and none used or disclosed for any purpose.

We collect these for the business purposes in Why we process it, and on what legal basis, from you and from the Service's own operation, and we disclose them to the providers in Who else sees it for those purposes. Retention is described in How long we keep it.

You have the right to:

• know what we collect, why, where it came from, who we disclose it to, and how long we keep it (this clause and the ones it points at are that disclosure);
• access a copy of the specific pieces of personal information we hold about you;
• correct inaccurate personal information;
• delete personal information, subject to the exceptions the statute allows and the limits in the clause above;
• not be discriminated against for exercising any of these. We won't degrade the Service, change your price or refuse you service because you asked.

Two rights don't apply to us, for the simple reason that the thing they protect against doesn't happen here: we do not sell personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of; and we don't use or disclose sensitive personal information beyond providing the Service, so there is nothing to limit. We honour Global Privacy Control signals by construction, since there is no sale or share to suppress.

Make a request by writing to support@zuuppa.com. We'll verify it against information we already hold, respond within 30 days, and tell you if we need the extension the statute permits. An authorised agent may act for you with written permission we can verify. We do not knowingly sell or share the personal information of anyone under 16, because we do not sell or share any.

You paid a merchant, and Zuuppa moved the money. Here's the short version of what that means for your data.

• We hold the payment itself: the address the funds came from, the amount and asset, the on-chain signatures and the timing. All of that is on the public blockchain regardless of us.
• If the merchant's checkout asked for your name, email or address, we hold those too, attached to that payment, on the merchant's instructions. Whether it asked is the merchant's choice, not ours.
• We don't create an account for you, we don't email you, we don't advertise to you, and we don't build a profile of you across the merchants you've paid.

For anything about your order (what you bought, whether it shipped, a refund, or deleting your details), contact the merchant you paid. They decide what happens to your data and they're the ones who can answer about the sale. We can't reverse a settled payment, and we can't speak for their side of it. If you don't know who they are, or they don't respond, write to support@zuuppa.com and we'll help you reach them and pass on your request.

Our infrastructure and our providers are primarily in the United States, so if you're elsewhere your personal data is transferred there and processed there. It may also be processed in other countries where our providers operate infrastructure.

Where a transfer out of the EEA, the UK or Switzerland needs a safeguard, we rely on the standard contractual clauses in our agreements with those providers, or on another mechanism the law allows. We don't yet offer those clauses in our own agreement with merchants; that's on the list in Changes and pre-launch commitments.

Blockchain data is replicated globally by design. A transaction on a public network is not transferred to a country: it is visible in all of them, permanently, and no safeguard changes that.

Only what the product needs to work. This is the complete list of what Zuuppa stores in your browser:

Supabase session: Local storage

Keeps you signed in between visits. Clearing it signs you out. Strictly necessary.

zuuppa-theme: Local storage

Remembers whether you chose the light or dark theme.

sidebar_state: Cookie, 7 days

Remembers whether the dashboard sidebar was collapsed.

zuuppa.demo.apiKey: Session storage

Holds the API key you paste into the in-dashboard demo, for that tab only. Gone when the tab closes.

No advertising cookies, no analytics cookies, no third-party trackers. There's no consent banner because there's nothing to consent to. Clearing them signs you out and forgets your theme. Our hosting provider may set its own cookies for security and delivery.

The Zuuppa mobile app shows a merchant their own account. It holds your session on the device, and if you enable notifications it registers a push token with the notification provider named in Who else sees it so we can alert you about your own payments. Turning notifications off in your device settings withdraws that consent. The app contains no advertising or analytics SDK.

Our checkout SDK, which merchants embed in their own apps, collects only the buyer fields that merchant enabled, and sends them to us to attach to that payment. It doesn't track a buyer's device or read anything else from it.

The Service is for businesses and is not directed at anyone under 18. We don't knowingly collect personal data from children. If we learn we have, we delete it. If you believe a child has given us data, write to support@zuuppa.com.

We'll update this page when our practices change, and the date at the top always reflects the current version. For a material change (a new category of data, a new purpose, a new kind of recipient) we'll email the address on your account before it takes effect rather than relying on you to re-read the page.

What we've committed to build before general availability

This policy names several places where our practice today is weaker than where it needs to be. Rather than leave those admissions scattered, here's the whole list, so you can hold us to it:

• Publish defined retention periods for each category of data, and build the deletion job that enforces them. Today nothing is deleted on a schedule.
• Offer a data processing agreement, with standard contractual clauses, to merchants who need one.
• Log every access to production data by our staff, so that access is auditable and not merely limited.
• Move the keys that hold in-flight funds into a managed key service, and split them so no single key covers every payment.
• Add two-factor authentication to the dashboard.
• Build self-service export and deletion, so a request doesn't depend on us handling an email.

None of these is a condition of the Service working today, and none of them changes what we collect. They are the difference between a policy that's honest and a policy we're proud of.

Privacy questions, or a request about your data, go to support@zuuppa.com. If you have an account, the support form reaches us with your account already identified.

Zuuppa Inc. is a Delaware corporation, established in the State of Delaware, United States, and is the controller of the personal data described here except where Who is responsible for what says a merchant is. We have not appointed an EU or UK representative or a data protection officer; write to the address above and it reaches the people who can act on it. This policy forms part of our Terms of Service.