Privacy Policy
Version 2026-10-14 · Last updated 14 October 2026
This document is an honest description of how Geat.io works today, published early so you can read it before you sign up. It has not yet been reviewed by a qualified lawyer. Items written as [LEGAL ENTITY] or [JURISDICTION] are placeholders that will be filled in at that review. Nothing here is legal advice, and the reviewed version will replace this one without changing how the service behaves.
This is a list of the records we actually hold, written from the database rather than from a template. We aim for the inventory below to be complete and we will correct it when it is not, so if you expect to see something here and cannot find it, write to us and ask.
Merchant data
Email address and password hash
Why: To create and secure your account, sign you in, and send account email. Passwords are stored as bcrypt hashes, never in readable form.
Kept: While the account exists. Retained after closure so the account can be restored and so credit balance stays attached to the right person.
Registration metadata: IP address, country, city, browser user-agent
Why: Abuse prevention and evidence in fraud or legal disputes. Country and city come from Cloudflare when that lookup is enabled; they are coarse, not a location fix.
Kept: For the life of the account record.
Session records: IP address, user-agent, creation, expiry, revocation
Why: So you can see and revoke your active sessions, and so we can investigate account takeover.
Kept: The row survives expiry and revocation: it is the record that shows where a sign-in came from. We have no automatic pruning job today, and we will say so here rather than imply one.
Audit log: action name, IP address, country, user-agent, timestamp, and event detail
Why: Security and fraud prevention, and the ability to establish, exercise, or defend legal claims. This is the record that shows who changed a payout key, who revoked an API key, and when.
Kept: Indefinitely, by design. See "Why some records are kept" below.
Two-factor secret and backup codes
Why: To verify your 2FA codes. The secret is encrypted at rest; backup codes are stored hashed.
Kept: Until you disable 2FA or the account is erased.
Extended public keys (xpubs) and derived receiving addresses
Why: To derive one-time payment addresses for your invoices and to watch the chain for payments to them. An xpub lets us compute your public addresses; it does not let us or anyone else spend your funds.
Kept: For the life of the account record, as part of the payment history.
Invoices, payments, credit purchases, and credit ledger entries
Why: To run the service, show you your history, and keep a correct record of what you were charged.
Kept: Indefinitely, as financial and anti-fraud records.
The IP address of the caller that created an invoice or requested an address through the API
Why: Abuse investigation and support: when two systems disagree about who created a record, this is the evidence. On API traffic this is normally your own server, not your customer.
Kept: With the invoice or address-request row.
API keys
Why: To authenticate your API calls. Stored as a hash plus a short non-secret prefix so you can tell your keys apart; we cannot show you a key again after it is issued.
Kept: Revoked keys keep their row, so the audit trail can still name the key that made a call.
Payment profile details: display name, website URL, contact email
Why: They appear on your hosted payment pages and in invoice email, so your customers know who they are paying.
Kept: For the life of the profile. Closing the account hides profiles rather than deleting them.
Notification channel credentials: Discord webhook URL, or Telegram bot token and chat id
Why: To deliver the payment notifications you asked for to the channel you chose. Only stored if you set a channel up.
Kept: Until you delete the channel. Encrypted at rest, because they are credentials.
Outbound email queue: recipient address, subject, and the full message body of every email we send
Why: Email is sent through a queue with retries, so the message is stored until it is delivered and the record of the attempt is kept afterwards.
Kept: Rows are not purged today. Anything in an email we send you or your customer is therefore held here too.
Payer data
Customer email address on the invoice, either supplied by the merchant or typed by you on the payment page
Why: So payment status email can be sent about that invoice, and so the merchant can match the payment to their order. The payment page offers an optional field for this; filling it in stores the address you typed.
Kept: With the invoice record, for as long as the merchant keeps their account.
The on-chain payment itself: address, amount, transaction id, confirmations
Why: To detect and confirm the payment. This data is public on the blockchain and is not ours to delete.
Kept: With the invoice record.
Tip-jar payments: your IP address, the email address you enter, and your optional message
Why: A tip page creates the invoice at the moment you click pay, so the request that creates it is yours rather than the merchant's. The IP address goes on the invoice row for abuse investigation; the email and the message go to the merchant, which is the point of them.
Kept: With the invoice record.
Invoice reports and reviews: your IP address, the reason you picked, your free-text note or comment, and your star rating
Why: Reports are how a payer tells us a merchant did not deliver, so they are evidence and we keep them as such. A review goes to the merchant and can be read back on that invoice's own payment page by anyone holding the invoice link.
Kept: Indefinitely. These are dispute records, kept for the same reason as the audit log.
Technical request data when you load a payment page
Why: Rate limiting, abuse prevention, and error diagnosis. Payment pages require no account and no sign-in.
Kept: In application logs. Log retention is set by the hosting arrangement we are finalising and will be stated here once it is live. The rows above are the cases where a payment-page action is stored in the database rather than only in a log.
Who else sees it
We use a small number of processors. Each one sees only what it needs for its job.
Resend
Transactional email delivery. Receives the recipient address and the message body for account email, invoice email, and security alerts.
Cloudflare
Turnstile human-verification on sign-up, sign-in, password reset, and the payer-facing forms (tips, invoice reports, reviews), plus network delivery. Cloudflare sees the IP address of the browser making the request.
ImageKit
CDN that serves the coin icons on payment pages and in the dashboard. Loading a payment page makes a request to ImageKit, so a payer IP address reaches them.
Blockchain data providers
Address and transaction lookups used to detect payments. They receive public addresses and transaction identifiers, not your identity.
Who is responsible for your data
For merchant account data, the controller is [LEGAL ENTITY], registered at [LEGAL ENTITY ADDRESS].
For the personal data of your customers that passes through an invoice, you are the controller and we act as your processor: we only handle it to run the payment flow you asked for.
What we do not collect
We do not ask merchants for identity documents, proof of address, or a selfie. There is no KYC step to open an account and no identity-verification provider in the signup flow.
We do not collect phone numbers, we do not run advertising or marketing trackers, and we do not sell or rent personal data to anyone.
Payers have no account with us. Loading a payment page does not create one.
We never hold your funds, so we hold no bank details and no payout instructions.
Legal bases (GDPR Article 6)
Performance of a contract: running your account, deriving addresses, detecting payments, sending transactional email, and charging credits.
Legitimate interests: security, abuse and fraud prevention, rate limiting, and keeping an audit trail. We balance this against your interests, which is why the audit trail records actions and technical metadata rather than content.
Legal obligation: accounting and tax records relating to credit purchases.
Consent: nothing in the service currently depends on consent, because there is no marketing mail and there are no non-essential cookies.
Cookies
The dashboard uses httpOnly cookies to hold your sign-in tokens. They are strictly necessary: without them you cannot stay signed in.
We run no analytics cookies, no advertising cookies, and no third-party trackers on the dashboard or on payment pages.
Why some records are kept
Audit log entries and financial records are retained indefinitely, and we do not delete them on request as a matter of routine. The ground is GDPR Article 17(3)(e): the right to erasure does not apply where the processing is necessary for the establishment, exercise, or defence of legal claims. A payment processor that deletes its record of who changed a payout key cannot defend itself, or a merchant, against the claim that the change was fraudulent.
That is a deliberate design decision, not a legal obligation we are passing on to you: we are not claiming an anti-money-laundering duty, because as a non-custodial software provider we do not take one on.
We will not pretend to an automatic retention schedule we have not built. There is no scheduled purge job today: records stay until someone asks us to remove them, or until we build one and say so here.
What happens when you close your account
Closure is a soft close. Sign-in is disabled immediately, every session and API key is revoked, and your payment profiles are hidden so no new invoices can be created against them.
Your account row, invoices, credit balance, and audit records are retained for the reasons above. Your prepaid credits are not refunded, but they are preserved: registering again with the same email address restores the account and its balance.
Full erasure is available on request. We do not run an automatic purge job, so ask us in writing and we will do it by hand, confirm what was removed, and tell you what we had to keep and why.
Your rights
You can ask for access to your data, correction, erasure, restriction, portability, or to object to processing based on legitimate interests. Write to support@geat.io from the address on the account. We answer within one month and we will tell you plainly if we cannot do part of what you asked and why.
If you are a customer of a merchant who uses Geat.io, ask that merchant first - they are the controller of their order data. If that does not work, write to support@geat.io and we will deal with it as a processor request.
You also have the right to complain to your national data protection authority.
Security
Passwords are bcrypt-hashed, two-factor secrets and other sensitive fields are encrypted at rest, API keys are stored hashed, and webhook payloads are HMAC-signed so your systems can prove they came from us. Outbound webhook delivery is checked against internal-network targets before the request leaves.
Hosting and data location: our production hosting is being finalised and we are not yet going to claim a jurisdiction we have not deployed into. EU-based hosting is the plan; the security page tracks the current posture, and this section will state the real answer once it is live rather than before.
International transfers
Some of the processors listed above operate outside the EEA. Where that is the case, transfers rely on the processor standard contractual clauses or an adequacy decision. This section will be finalised with the hosting decision.
Changes to this policy
Each version carries a version date, and the version in force when you registered is stored against your account. Material changes are announced by email to the address on your account before they take effect.