Privacy
Payment security assessment
How we weighed the data LatchPay records at the checkout to protect payments, and what LatchPay Protect does with it: the legitimate-interest assessment and the data protection impact assessment. Version 1.0, 13 October 2026. It leaves out details that would help someone get around the fraud checks.
1. Who decides
The merchant who runs the store is the controller of its buyers' data, and LatchPay processes that data for the merchant (see the Data Processing Agreement). LatchPay designed this processing and made this assessment for its merchants, who can rely on it and add their own. The data of one merchant is never used for another.
2. What is processed
| Processing | Where |
|---|---|
| At payment: the IP address, browser user agent, language and time zone of the request, and a random device id in a checkout cookie (stored only as a code) | Every store |
| What the payment provider reports about the card and its checks (such as 3-D Secure, the address and security-code checks, the card's fingerprint) | Every store |
| The fulfilment status and tracking of a LatchPay order, read from Shopify | Every store |
| Fraud checks and the store's blocklist at payment | Stores with LatchPay Protect |
| Automatic actions on a card network's alert or a dispute: refund, cancel the Shopify order, stop subscriptions, block the buyer | Stores with LatchPay Protect |
| Preparing dispute evidence and sending it to the merchant's payment provider | Stores with LatchPay Protect |
| Deleting the data when its period ends, or on request | Every store |
The payment-security data is recorded only when a buyer presses Pay and a payment starts. It is not recorded for subscription renewals, which happen without the buyer.
3. The purpose
- Preventing fraud on the merchant's payments. The GDPR names this as a legitimate interest (recital 47).
- Answering wrongful chargebacks. A chargeback costs the merchant the sale, the goods and the provider's fees. Card networks accept as evidence that the same device or network bought from the same merchant before without a dispute; Visa's Compelling Evidence 3.0 asks for earlier undisputed purchases that are 120 to 365 days old.
- Protecting cardholders. After a fraud report the cardholder gets the money back quickly, and a stolen card cannot be used again at that store.
These interests are lawful, specific and present: fraud and chargebacks happen with every kind of online card payment.
4. Is the data necessary?
- The IP address is itself part of the evidence card networks ask for, so a code alone is not enough. It is stored encrypted, with a code per merchant for comparing payments.
- The device id recognises the same browser at the same merchant. Only a code of it is stored, different for every merchant.
- The browser user agent, language and time zone describe the device in the evidence. Whether a shorter summary of the browser is enough is one of the points we keep under review.
- The card details from the payment provider recognise the same card and show which security checks passed, which card networks weigh in a dispute.
- 13 months follows from the evidence rules: purchases up to 365 days before a dispute count, plus a margin.
Less intrusive options we considered:
- Recording only on stores with Protect. Not chosen: the evidence needs purchases made before a dispute, so it would work only months after a merchant turns Protect on.
- Setting the device cookie only with consent. Not chosen: a security check that a fraudster can decline does not protect the payment. Without the cookie the evidence relies on the IP address alone.
- A list shared between merchants. Rejected as more intrusive: every list belongs to one store.
- Never declining automatically. Partly chosen: a match on only a device or network holds the order for the merchant's review instead of declining it.
5. The balance
No special categories of data are processed. The data does include online identifiers, data about the means of payment and purchase history, which weigh more heavily.
Buyers expect a fraud check when they pay online by card, that a store keeps proof of delivery, and that a card reported as stolen is declined. They may expect less a cookie that lasts 13 months, that this also happens on stores that do not use Protect, that details of earlier purchases go to their bank in a dispute about a later one, or that a store blocks them without saying so. The privacy notice and this page explain these points, and the checkout links to the merchant's own privacy policy.
The effects stay within one store: a block or a decline at one merchant has no effect anywhere else. The safeguards are in sections 7 and 9 and in the DPA.
Outcome. On stores with LatchPay Protect, the merchant's legitimate interest outweighs the buyer's interests, given these safeguards (article 6(1)(f) GDPR). On stores without Protect the data is recorded but not used until the merchant turns Protect on. That is the weakest part of the balance, and there it tips only narrowly towards the merchant: evidence can only come from purchases made before a dispute, the data stays within that merchant, and it is deleted after 13 months. It is the first point of our next review.
The device cookie is set without asking because it is a strictly necessary security cookie for the payment the buyer asked for: it is set only after Pay is pressed, holds a random id and nothing else, can be read only by the checkout, and is never used for analytics or advertising.
6. Why an impact assessment
The Dutch data protection authority lists fraud prevention and blacklists among the processing that needs a data protection impact assessment, and LatchPay Protect scores payments, makes automatic decisions, combines reports from banks with checkout data, and can refuse a purchase. Today the scale is small, but the processing is built for every store, so we made the assessment before the release.
7. Automatic decisions and human review
With LatchPay Protect, some decisions are taken automatically, within the settings the merchant chooses:
- declining a payment that matches the store's blocklist on e-mail address or card;
- declining a payment the fraud rules rate as high risk, or holding it for the merchant's review;
- after a fraud warning or a pre-dispute alert: refunding an unshipped order, stopping the buyer's subscriptions with that store, adding the buyer to the store's blocklist and, only if the merchant turns it on, cancelling the Shopify order;
- after a dispute: adding the buyer to the store's blocklist;
- sending prepared dispute evidence to the merchant's payment provider before the deadline.
The merchant relies on these decisions being necessary to enter into a safe purchase with the buyer (article 22(2)(a) GDPR), with these safeguards: each automatic action can be switched off per store; the merchant sees every action and its reason; the merchant can approve held orders, remove any block and refund at once; and a declined buyer sees "We could not complete this payment. Please contact the store." The buyer can ask the store to review the decision by a person, explain their side and contest it.
8. How long the data is kept
| Data | Kept |
|---|---|
| Payment-security data of a checkout (IP address and user agent, encrypted; language; time zone; the codes) | 13 months after the payment started, deleted every night |
| The device cookie in the browser | Up to 13 months from the first payment in that browser, not renewed |
| An order's card fingerprint | 13 months after the payment |
| Other card and check details, fulfilment status and tracking | With the order, which is kept for seven years under Dutch tax rules |
| Blocklist entries | An IP address 30 days, every other entry 13 months, or sooner when the merchant removes it; a new fraud report or dispute starts the time again; removed and ended entries are deleted within 30 days |
| The buyer's personal details in prepared dispute evidence | 180 days after the dispute is decided, at most 13 months after it was opened |
| Evidence already sent | Kept by the merchant's payment provider under its own terms |
| LatchPay Protect notices to merchants (no personal data) | 400 days |
9. Risks and measures
The remaining risk is the risk after the measures that are in place today.
| Risk to buyers | Measures | Remaining |
|---|---|---|
| A buyer is declined or blocked by mistake, for example because someone else typed their e-mail address or a bank reported fraud in error | Lists are per store and expire; the merchant can remove any entry at once; a match on only a device or network leads to the merchant's review, never to a decline | Medium |
| A buyer's subscription is stopped by mistake | Only with the same e-mail address and a shared payment trace (same card, device or network); the merchant sees every action and its reason | Low |
| A genuine order is refunded or cancelled after an alert | Only orders that have not shipped; cancelling the Shopify order is off unless the merchant turns it on; never twice, never after a dispute | Low |
| Others on the same device or network (family, office, public Wi-Fi) are affected | Such a match only holds an order for review; an IP address leaves the list after 30 days | Low |
| Dispute evidence carries a lot of data to the payment provider, the card network and the bank, also outside the EEA | Only to the merchant's own payment provider; earlier purchases count only at the same merchant, with the same card and the same device or network, and never ones that were disputed; the merchant can read and change the evidence first | Medium |
| A data breach or access without a right | Encryption and keyed codes, the raw device id never stored, access limited to LatchPay's administrators with every admin-console view of a merchant logged, no personal data in logs (see the DPA, Annex 2) | Low |
| A buyer is followed across stores | Codes differ per merchant, lists are never shared, and only the dispute-evidence code opens the encrypted IP address and browser | Low |
| Buyers do not know about the processing | This page, the privacy notice and the help for merchants; the checkout links to the merchant's own privacy policy | Medium |
| Rights are hard to use | The merchant forwards requests and LatchPay deletes what it holds for that merchant (see "Your rights" below) | Medium |
| Data is kept longer than needed | Fixed periods with nightly deletion; the evidence details are removed after the dispute | Medium |
Data that goes to providers outside the European Economic Area travels under an adequacy decision or the EU standard contractual clauses; evidence that a payment provider passes to card networks and banks follows that provider's own terms.
10. Conclusion
Article 6(1)(f) GDPR is the legal basis. With the measures in place, no high risk to buyers remains, so a prior consultation of the Autoriteit Persoonsgegevens (article 36 GDPR) is not needed.
Further measures we plan, not in place yet:
- a model text merchants can add to their own privacy policy about the payment checks and the blocklist;
- guidance for merchants on handling a buyer's objection to a decline within a month;
- a decision on the data of stores without Protect: as now, a shorter period, or a switch for the merchant;
- keeping a shorter summary of the browser instead of the full user agent, and deleting card check details sooner;
- a lookup that shows a merchant everything LatchPay holds for one buyer.
Your rights
Buyers use their rights through the store they bought from; the store asks us to help. On a deletion request we delete the payment-security data, the prepared dispute evidence and the card codes we hold for that merchant; the merchant decides whether a blocklist entry stays to prevent fraud. You can object to this processing (article 21 GDPR) the same way. You can always complain to the Autoriteit Persoonsgegevens. More in the privacy notice; questions through the contact form.
Review
We review this assessment at least once a year (next by 13 October 2027), and sooner when a new party joins the alerts, the decision about the cookie changes, a payment provider is added, a feature would work across merchants, or the number of stores grows substantially.
Who we are
- Name
- LatchPay
- Legal form
- sole proprietorship (eenmanszaak)
- KvK number
- 74998129
- VAT number
- NL002373677B66
- Address
- Pinksterbloemweg 255, 1508 BT Zaandam, the Netherlands
- info@latchpay.io
- Contact
- Contact form; we answer by e-mail.