Legal

Data Processing Addendum

Last updated: 10 November 2026

How GiftingStack processes personal data of your end users on your behalf. It forms part of the Terms of Service.

1. Scope and roles

This addendum applies when GiftingStack processes personal data on behalf of a customer while providing the Service. The customer is the controller (or the processor of its own customers) and GiftingStack is the processor (or sub-processor). Each party follows the data protection law that applies to it, including the GDPR and the UK GDPR where relevant. For the customer's own account data, GiftingStack is a controller, as described in the Privacy Policy.

2. Details of the processing

• Subject matter: running the gifting API, balances, ledger and webhooks.
• Duration: for as long as the customer uses the Service, then as set out in section 9.
• Data subjects: the customer's end users.
• Types of data: a customer-chosen identifier (external_id), balances and ledger entries, gifts sent and received, optional messages (up to 280 characters), optional metadata (up to 2 KB), webhook event records and, in gift rooms, the display name the customer sends and the scores of an open battle round. When the customer uses receipt validation or store notifications, also store purchase records (see below). A credit may also record a price and currency (declared by the customer or taken from a verified receipt); this adds nothing about the end user beyond the credit itself, but as part of a credit it can still be personal data.
• Special categories: none intended. The customer must not send them.
• Purpose: providing the Service to the customer.

Receipt validation and store notifications

These features are off unless the customer turns them on; on the live environment, store sales are recorded for billing through verified receipts. If the customer submits purchase receipts for verification, or connects App Store Server Notifications or Google Play Real-time Developer Notifications, GiftingStack processes the store's purchase records as the customer's processor: transaction and order ids, product ids, prices and currencies, purchase, renewal and refund dates and the notification type (and a hash of the customer's user identifier sent with a receipt). The receipts are submitted by the customer; the notification payloads are sent by Apple and Google on the customer's instructions, to the URL the customer configures. They contain no payment card or bank data. The purposes are to confirm that a purchase is real and unused and to detect refunds, which are reported to the customer (a purchase.refunded webhook event). Apple and Google are therefore sources of data the customer chooses to send us, not sub-processors of GiftingStack. For Google Play, GiftingStack also reads the order's price from the Google Play Developer API with the customer's own service account. GiftingStack never receives, holds or moves the money; it does not change any balance because of a notification. The records are kept while the project exists. Notification contents are not written to our logs.

Sale records and the service fee

GiftingStack uses the prices on credits (verified store receipts, and web sales the customer declares) and store refunds to calculate and check its service fee, as described in the Terms of Service, and converts them to US dollars with the European Central Bank's public daily reference rates, which contain no personal data. For calculating, checking and collecting its own fee GiftingStack decides how these records are used, so for that purpose it acts as a controller under its Privacy Policy, not as the customer's processor. It uses them for nothing else.

3. Our obligations

• Process the data only on the customer's documented instructions, which are these terms and the customer's use of the API and dashboard, unless the law requires otherwise. We will tell the customer if we think an instruction breaks the law.
• Make sure people allowed to process the data are bound by confidentiality.
• Apply the security measures in section 4.
• Use only the sub-processors in section 5, under written terms with similar data protection duties.
• Help the customer answer requests from data subjects, for example through the user deletion endpoint (DELETE /v1/users/{external_id}) and the read endpoints for access and export requests, and with security, breach notification, data protection impact assessments and prior consultation with a supervisory authority, by giving the information we have about the processing, taking into account its nature.
• Tell the customer without undue delay, and in any case within 48 hours, after we become aware of a personal data breach affecting its data, by email to the customer's account address, with what we know about the nature, the data affected and the measures taken. Customers can report a suspected incident to support@giftingstack.com.
• Give the customer the information needed to show we comply with this addendum, on reasonable request, and allow audits. Audits are done by written questionnaire and documentation first. If that is not enough to show compliance, or a supervisory authority requires it, the customer or an auditor it appoints who is bound by confidentiality may carry out an inspection, on at least 30 days' written notice, at the customer's cost, limited to the processing under this addendum and to what does not expose other customers' data, and no more than once a year unless there has been a personal data breach.
• When the Service ends, delete or return the personal data at the customer's choice: the customer can export it through the API, and project deletion then erases it as set out in section 9, unless the law requires us to keep it.

4. Security measures

• Encryption in transit between clients and the Service.
• Each project and environment (test and live) is stored in its own isolated storage unit. The unit is chosen only from the authenticated API key.
• API keys, session tokens and sign-in tokens are stored only as hashes. Webhook signing secrets are stored encrypted.
• Webhooks are signed so the receiver can verify them.
• The live ledger is append-only (the test ledger can be reset by the project owner). Every change records a reason, an actor and a request identifier.
• Our own logs and service metrics do not contain gift messages, metadata or end-user identifiers. Cloudflare's automatic request logging is switched off for the API and rooms Workers.
• Identifiers containing "@" are rejected, to keep email addresses out of end-user identifiers.
• Rate limiting and access checks on every dashboard and API request. Bot checks (Cloudflare Turnstile) on sign-in.
• Access to production data is limited to the owner of GiftingStack, who can technically read project data when needed to run or support the service. Dashboard sign-in is by emailed link, with no second factor. We do not have an independent security certification or a penetration test report.

5. Sub-processors

The customer authorises the following sub-processors:

• Cloudflare, Inc.: hosting, networking, storage, queues, bot checks (Turnstile) and email forwarding for all Service data.

Resend (sign-in and team-invitation emails) processes only the customer's account data, not end-user data. Creem is the merchant of record for paid plans and processes only the customer's account and billing data, not end-user data. This list is the same as in the Privacy Policy. We will tell customers by email or in the dashboard at least 15 days before adding or replacing a sub-processor that handles end-user data, where we reasonably can. A customer can object on reasonable data protection grounds within that time; if we cannot resolve the objection, the customer can stop using the affected Service and ask us to delete its data. We remain responsible for our sub-processors as the law requires.

6. International transfers

Cloudflare operates a global network. The project region a customer selects is a placement preference and not a guarantee of where data is processed. Where data is transferred outside the EEA or the UK, we rely on appropriate safeguards, such as standard contractual clauses, offered by our sub-processors. GiftingStack itself is operated from the Republic of Türkiye. We have no signed transfer mechanism of our own (standard contractual clauses, UK addendum) and no KVKK registration or certification to offer today; this is an open item. A customer that needs one for its use of the Service should write to support@giftingstack.com before sending personal data.

7. The customer's responsibilities

• Have a lawful basis for the processing and give end users the notices the law requires.
• Do not put personal data into metadata or messages beyond what you need. This is the customer's responsibility.
• Use the deletion endpoint when an end user asks to be erased.
• Keep API keys secret and revoke those that may be exposed.

8. Deletion requests and backups

When the customer deletes an end user, the identifier is replaced with a random one, messages and metadata are erased from gifts, ledger entries, stored events and stored request results, and the balance is closed by a ledger entry. Store purchases verified for that end user lose the keyed hash that linked them to the identifier. Amounts, dates and reasons remain under the new random identifier; we keep no record of the old one. This is pseudonymisation, not anonymisation: whoever still holds the old identifier (the customer) may be able to link the records again, so we keep treating them as personal data. Our backups and point-in-time recovery allow recovery for up to 30 days (for one database product 7 days, depending on our Cloudflare plan), so deleted data can remain in backups for that time and is then removed. We do not restore deleted data into the Service.

These limits apply to every deletion, including project and account deletion:

• Webhook messages already waiting in a queue for retry (up to 5 days) carry the old payload until they expire; once the project's endpoints are gone they are sent nowhere.
• When a gift receiver is deleted, the sender's refund ledger entry keeps its metadata: it is the sender's record.
• A gift room erases everything it stores about 6 hours after its last viewer left and its battle round ended; deleting an end user does not change a round that is still open.
• Cloudflare's short-lived logs and service metrics (a few days to about 3 months) contain no end-user data. Copies the customer holds itself, such as webhook events already delivered, are the customer's responsibility.

9. End of the Service

When the customer ends the Service, the project owner can delete each project in the dashboard. The project's API keys stop working at once; the owner can cancel for 7 days; after that a daily job permanently erases the project's data (end users, balances, ledgers, gifts, events, catalog, keys, webhooks, team and store records) from live systems, normally within about 8 days of the request, and it leaves Cloudflare backups after up to 30 days more (so about 38 days in total). The owner can also delete the account once it owns no project, and we may delete projects without the grace period if an account breaks the Terms seriously. Before deleting, the customer can export data through the API; during a suspension, reads remain available. We may keep data the law requires us to keep, such as invoices, for the legal period. The limits in section 8 apply.

10. Liability and order of precedence

Liability under this addendum is subject to the limits in the Terms of Service, except where the law does not allow them. Nothing in this addendum limits the rights of data subjects or the powers of supervisory authorities, or relieves either party of its own duties under data protection law. If this addendum and the Terms conflict on the processing of personal data, this addendum applies; mandatory law prevails over both.

11. Contact and signed copy

This addendum applies automatically when you accept the Terms of Service. If you need a signed copy, write to support@giftingstack.com.