Valence Easy Loyalty runs loyalty programmes for shops. A shop's customers join the shop's programme, not ours. So almost everything on this page is about data that the shop controls and which we process on the shop's instructions, and for no other purpose.
Who is responsible for what
- Your customers' data. The shop decides why it is held and what is done with it, so the shop is the controller and Valence Easy Loyalty is the processor. We act on the shop's instructions and on nobody else's.
- The shop's own people. The owner and staff who sign in to the console are our own customers, so for their names, email addresses and sign in records we are the controller.
- A few things we decide ourselves. Keeping the service secure, meeting our own legal obligations, keeping our business records and our contract with the shop, and defending ourselves if we ever have to. For those we are the controller, because nobody instructs us to do them.
That last one is narrow, and it is worth saying what it does not cover. It does not extend to marketing anything to a shop's customers, to profiling anybody, or to building any collection of people outside the programme they joined. A shop's members are the shop's.
Children
Valence Easy Loyalty is built for ordinary retail loyalty and is not aimed at children. We do not ask for a date of birth, and we do not ask for age.
That is not the end of the question. The Information Commissioner's Office takes the view that the rules protecting children apply where a service is likely to be accessed by them, not only where it is aimed at them, and some shops running a programme will be places children go: a sweet shop, a café near a school, a leisure centre. So it is a question each shop has to consider for its own programme, and we will help a shop that needs to work through it.
If you believe a child has joined a programme and you would rather they had not, tell the shop, or write to us at info@easyloyalty.co.uk, and the account can be closed and the details removed.
What we hold about a member
| What | Why |
|---|---|
| A name, if they gave one | So a till can greet them. Optional at signup and a programme works without it. |
| One way to reach them: an email address or a mobile number | To send a sign in code, a receipt, or an offer if they asked for offers. |
| A card number | Their membership number, printed or held on their phone. |
| A secret used to make the rotating code | So the code on their phone can be checked at the counter and cannot be reused. |
| Their points, and the sales that earned them | The basket lines, the amount, the time, and which shop or branch it was. |
| What they said they like, and what they agreed to | To put relevant offers first, and to know whether they asked to hear from the shop. |
| Sign in sessions and any passkey they set up | To keep them signed in to their own card and to let them back in. |
There is no street address field anywhere in the product. We do not hold card or payment details at any point, and no payment ever passes through us.
The contact address is encrypted, and only opened for a named reason
- It is encrypted at rest with AES-256-GCM, under a key derived separately for each shop, so the same person shopping at two programmes produces two unrelated values and nothing here can answer "where else does this person shop".
- Finding a member by their address uses a keyed fingerprint rather than the address itself.
- Decrypting it requires a stated reason from a fixed list: signing in, account recovery, a receipt or other transactional message, marketing, a subject access request, or the shop's own export. Anything else is refused by the software rather than discouraged by a policy.
- The marketing reason returns nothing at all unless that member ticked the box.
What this protects against, stated plainly so nobody oversells it: a stolen database, a leaked backup, a copy of a row in a log, a snapshot handed to somebody who should not have it. It does not protect against an attacker who has taken over the running application, because the application has to be able to send the sign in code. That is a real and worthwhile difference and it is not the same as not holding the data.
What we deliberately do not keep
- Browser and device details. A sign in record says "iPhone, Safari" rather than the full user agent string.
- Anything extra on an online order. A Shopify order arrives carrying a delivery address, a billing address, the shopper's IP address, notes the shop wrote about their customer and any gift message. We keep the basket, the amount, the time and which member it was. The rest is discarded, and there is an automated test that pushes an order full of those things through and fails if any of them survives.
- Order history. We receive a message when an order is paid, refunded or cancelled. We never call Shopify to retrieve or search past orders, and the code that could do so is refused by an allow list rather than by convention.
- Who searched for whom. When a shop searches its members, the search term is stored as a fingerprint and the results are never stored.
- Invitations, after ninety days. Only a fingerprint is kept so the same person cannot be invited twice, and it is purged after ninety days.
Marketing
- Off unless the member asks for it. The box is unticked when they join.
- One press to switch it off, in their own app.
- No member is emailed something promotional more than once every sixty days.
- Notifications on a phone have their own limit, at most three a day for promotions and three a day for new rewards, because a notification is asked for twice over and dismissed in a second where an email sits in an inbox. Both limits are enforced in one place that every promotional message passes through.
- Receipts, sign in codes and messages about their own points are not promotional and are not covered by that limit.
What a member can do
- Download everything held about them, from the app, without asking anybody.
- Close their account, from the app. Their personal details are removed from the active system straight away, and from our backups as those backups age out within seven days. The points entries stay, without a name attached, because a shop's accounts have to add up.
- Ask the shop to correct anything. The shop can do that from its console.
How long we keep it
| What | How long |
|---|---|
| Member record and contact address | While they are a member of that programme, and until they close their account or the shop closes its programme |
| Points entries and sales | Six years from the date of each sale, to support loyalty account reconciliation, auditability and the shop's record keeping requirements. After that the detail goes and the balance is carried forward, so nobody loses points. Personal details are removed when a member closes their account, the entries are not |
| Invitation fingerprints | Ninety days, then purged automatically |
| Change history and access records | Two years |
| Sign in sessions | Until they expire or the person signs out, and immediately if their access is removed |
| Everything, after a shop leaves us | Thirty days, so a shop that leaves by mistake can come back, then deleted |
Where it is held, and who else sees it
Our application and database are hosted in the European Economic Area, in Ireland. Transfers from the United Kingdom to the EEA are permitted under the United Kingdom's adequacy regulations.
Some specialist providers process limited data outside the EEA where that is necessary to provide the service. Where that happens, appropriate transfer safeguards are used, and the table below says which provider, what for, and where.
| Who | What for | Where |
|---|---|---|
| Supabase | The database | Ireland, eu-west-1 |
| Vercel | Running the application | Ireland, eu-west-1 |
| Resend | Sending sign in codes, receipts and other transactional messages | United States. Transfers are protected by appropriate safeguards under Resend's data processing agreement, including Standard Contractual Clauses and the UK Addendum |
| Issuing a wallet pass, for members who choose to add their card to a phone wallet. It receives the member's name, their membership number, their points balance and tier, and the shop's colours. It receives no email address and no phone number | Per Google's own terms |
These are the third parties currently used by Valence Easy Loyalty to provide the service.
Square, Shopify and Toast are not among them. Those are the shop's own systems, and data moves from them to us rather than us passing anything on. Where we create a discount code in a shop's Shopify checkout at a member's request, we send what the reward needs and nothing about the member.
Two things that reach other companies, and carry nothing about anybody
- Notifications are delivered through the push service your own browser chose, which is usually run by Google, Apple or Mozilla depending on the browser. We do not pick it and we have no contract with them. The message we send them is empty: it is a signed request with no content, and the words you see are fetched by your own phone from us afterwards. So nothing about you reaches a push service.
- Search engines are told when one of our own marketing pages changes. That is about our pages and carries no personal data of any kind.
Nothing else runs in your browser
No analytics, no advertising pixel, no tag manager, no embedded fonts and no content delivery network. Every file a page needs is served by us, so visiting Valence Easy Loyalty makes no request to any other company. The whole product has two third party software libraries in it, one to talk to the database and one for passkeys.
We do not sell personal data, share it with advertisers, or use member data to train AI models. The optional writing assistant in the console refuses any text containing an email address, a phone number, a card number or a member id, and it is switched off unless a shop turns it on.
How it is protected
- Encrypted in transit, and encrypted at rest, with the contact address separately encrypted on top of that.
- Backups are encrypted, in transit and at rest, taken daily, and stored on a system separate from the live database. They are kept for seven days and then age out.
- Test and live are separate projects with separate data. No real member data is used for testing.
- Staff in a shop are named individuals with defined permissions rather than a shared password. Removing somebody ends every session and passkey of theirs immediately.
- Reads of member data are recorded: who looked, when, and what they searched for as a fingerprint.
- Sign in is by one time code or passkey. There are no passwords to leak.
Cookies
One cookie, holding the sign in session, which a script cannot read. No advertising cookies, no tracking pixels, and no third party analytics on the member app or the console.
Asking us something
If you are a customer of a shop that uses Valence Easy Loyalty, ask the shop first: the data is theirs and they can answer most things from their console. If you would rather come to us, or the shop cannot help, write to info@easyloyalty.co.uk.
If you are not happy with how we have handled something, you can complain to the Information Commissioner's Office at ico.org.uk.
- The company is named now: Valence Dynamics Ltd, company number 17479617, of 20 Beverley Gardens, Stanmore, England, HA7 2AD. What is still missing is the ICO registration number, which cannot be filled in until the registration is made.
- The hosting, backup and data location claims have to be verified against the production configuration as it actually is on the day this goes live, not as it is intended to be. In particular the Live database has to be on the Supabase Pro plan: the seven day backup window above is Pro's, and the free plan takes no automatic backups at all, so those sentences are not true of Live today.
- Every sub-processor named above has to be in use and under a data processing agreement on the day this goes live. A list that is aspirational in either direction, naming one we do not use or omitting one we do, is the failure this page exists to avoid.
- What happens to a member who simply stops coming has to be decided. Today their record is kept for as long as the programme runs, because they have not closed their account and nothing else deletes it. That is a defensible position and it is not currently a stated one.
- Done. The retention periods above are enforced rather than stated: expired entries are purged, the balance is carried forward first so nobody loses points, and the change history is kept two years.
Last updated 22 September 2026.