Data Processing Agreement

1.Parties and roles

This Data Processing Agreement (GDPR Article 28) is concluded between the business that registers a partner account, as the controller ("you"), and Heatrail OÜ, registry code 16731349, Estonia, as the processor. It is concluded by accepting it at registration, and it forms part of the Terms of Service. It applies for as long as your account processes data through Heatrail.

2.Subject matter and purpose

Heatrail processes personal data of your customers for one purpose only: to prevent and detect payment fraud in your store. Your checkout sends signals to the Heatrail API when an order is placed; Heatrail returns an advisory risk score. Heatrail makes no automated decision producing legal or similarly significant effects: the system is designed so that it cannot block, delay or cancel a purchase (fail-open).

3.Categories of personal data

Your store transmits the following, and nothing else: the API accepts a closed list of fields and rejects any field it does not know.

• irreversible hashes of e-mail address and phone number (two-stage HMAC; the first stage is computed on your own server, so the raw address or number never reaches Heatrail, and only the second-stage value is stored)
• the customer's IP address
• connection metadata that your own server observes as it accepts the order request: the source port of that connection, its timestamp (UTC, to the millisecond) and the address and port of the server that received it. Where an internet provider shares one address among many subscribers, the address alone is often not enough for that provider to find a connection in its records; the three values together are. They are held as evidence only: they are never used in the risk score, in velocity analysis, in the link graph or in the heat set, and they never affect any decision about a purchase. They leave Heatrail solely inside an evidentiary report that a human operator has approved and sends by hand, and they are produced by your own server accepting a connection the browser makes anyway — nothing is stored on or read from the customer's device for them
• generic device attributes — only where you have switched that layer on, and only from this closed list: screen width and height, device pixel ratio, processor cores, memory class, touch support, time zone, up to eight language preferences, platform, a coarse user-agent class, and two rendering fingerprints (canvas_hash and webgl_hash)
• generic order attributes, as categories and bands only — never an exact amount, a product name or free text: product risk class, quantity, amount band, account-age class and referrer class
• an order reference and a session pseudonym issued by your store, and — where your integration sends one — a first-party persistent identifier for the browser, which is matched inside your own store only and never across stores

Not transmitted: names, addresses, payment instrument data, order contents, raw contact details.

4.Categories of data subjects

Customers of your store who place an order.

5.Heatrail's obligations

1. processes the data only on your documented instructions - this agreement and your configuration, including your right to stop the processing at any time with the integration's off switch, without Heatrail's involvement;
2. ensures that persons with access to the processing are bound by confidentiality;
3. applies technical and organisational measures (Article 32), including: encrypted connections, signed requests (HMAC), an append-only event chain, two-factor authentication on operator accounts, an audit trail, and data minimisation by hashing. On the append-only chain, stated precisely rather than generally: since 2 September 2026 it is enforced by database privileges — the database role the application connects with at runtime holds INSERT and SELECT on the event chain and the access log and is denied UPDATE, DELETE and TRUNCATE, and the application code itself refuses every update or deletion of a chain entry, so neither that connection nor that code can rewrite either of them. That protection binds the runtime role and the application; it does not bind the separate owner credential the hosting platform holds for schema changes, which Heatrail keeps out of the processes that serve requests but cannot remove from the platform. Against anything that reaches that credential, the chain relies on detection: every entry is covered by a hash chain, by a record of the chain's length kept outside the database, and by the nightly Ed25519-signed anchors, which detect alteration rather than prevent it. Entries written before 2 September 2026 have that detection only, not the privilege-based prevention;
4. engages no sub-processor without informing you in advance. Sub-processor in use: Laravel Cloud / Amazon Web Services (EU-Central, Frankfurt) for infrastructure and database hosting;
5. assists you in responding to data subject requests;
6. notifies you of a personal data breach without undue delay after becoming aware of it;
7. makes available the information needed to demonstrate compliance with this agreement and allows for audits.

6.Retention

The checkout signals used for scoring — the hashes, the IP address, the connection metadata, and the device and order attributes — are deleted 90 days after the check by a scheduled daily job, together with the identity graph built from them. A record bound to an active fraud or chargeback incident is kept for longer, as evidence to establish or defend a legal claim (Article 17(3)(e)); you will be informed.

Four categories outlive that window, and this agreement names them rather than rounding them down:

• Incident, notification, grouping and memo records — a recorded fraud or chargeback label, an alert sent to your store, the fraud groupings built from them, and any authorities memo drafted from them — currently have no automatic deletion date. They carry your own order reference and the outcome, never a name, a contact detail or order contents, which Heatrail does not receive at all. Setting a retention limit for them is a known open item on Heatrail's side.
• The append-only event chain and the access log are kept permanently, by design, so that no record of what the service did can be altered afterwards. Of your customers' data they hold references only — record identifiers, your order reference, short hash prefixes — never a full hash, a contact identifier or a device profile.
• Cached responses to repeated requests (used to make a retried check idempotent) expire after 24 hours, but the expired entry is overwritten only when the same request recurs; an entry whose request never recurs is retained.
• Entries in the in-memory risk cache stop counting towards a score once they expire, but may remain physically stored beyond 90 days until a sweep is implemented.

Finally, and for completeness: encrypted database backups and point-in-time recovery are retained for 7 days, so a deleted or erased record can survive in a backup for up to a week after its deletion.

7.Termination

On termination Heatrail will, at your choice, delete or return all personal data processed on your behalf, unless retention is required by law or by section 6 above.

8.International transfers

All processing takes place within the European Union. Heatrail will not transfer personal data outside the EU/EEA under this agreement without concluding the safeguards the GDPR requires and informing you first.

9.Liability and governing law

Estonian law applies. This agreement does not limit either party's statutory liability.

10.What changed in this version

Version 1.0309261139.3 replaces version 1.0309260910.2 (effective 2026-09-03) with one correction to section 5(3), described in the fourth item below; sections 1 to 4 and 6 to 9 carry the earlier wording word for word. Version 1.0309260910.2 had replaced version 1.0209262226.1 (effective 2026-09-02) without altering a single obligation, changing only how the document is presented and removing the provisional marking the earlier version carried; version 1.0209262226.1 in turn replaced version 1.0 (effective 2026-09-01). No earlier version is edited and none is withdrawn: each stays available, byte for byte, at its own permanent link, because acceptances were recorded against it. The corrections made since version 1.0, all of them making the text narrower or more exact — none of them widening what Heatrail may do:

• Section 3 now lists the data categories the API actually accepts. Version 1.0 omitted the referrer class, did not name the two rendering fingerprints inside the device layer, did not mention the first-party persistent identifier, and predated the connection metadata described above.
• Section 5(3) stated without qualification that the append-only event chain is "enforced by database privileges". That became true on 2 September 2026 and was not true earlier in the life of version 1.0. The clause now carries the date, and says what protects the earlier entries instead.
• Section 6 stated that signals and derived heat are kept for up to 90 days "and are then deleted automatically", with confirmed fraud as the only exception. That is true of the checkout signals and the identity graph, but not of incident, notification, grouping and memo records, of the permanent append-only chain and access log, of cached idempotent responses, or of the in-memory risk cache. Those four are now named.
• Section 5(3), as worded in versions 1.0209262226.1 and 1.0309260910.2, said that a compromise of the application cannot rewrite the event chain. That was too broad. The database privileges bind the role the application connects with; the hosting platform also holds an owner credential that those privileges do not bind. The clause now says exactly what the privileges and the application code cover, what is kept out of the request-serving processes, and that everything beyond that rests on detection.