Document versions
Ta dokument je na voljo samo v angleščini.
Current versions
privacy: Različica 2026-09-23. Velja od 2026-09-23.terms: Različica 2026-09-23. Velja od 2026-09-23.terms-business: Različica 2026-09-23. Velja od 2026-09-23.terms-partner: Različica 2026-09-23. Velja od 2026-09-23.dpa: Različica 2026-09-15. Velja od 2026-09-15.cookies: Različica 2026-09-15. Velja od 2026-09-15.delete-account: Različica 2026-09-23. Velja od 2026-09-23.imprint: Različica 2026-09-15. Velja od 2026-09-15.subprocessors: Različica 2026-09-06. Velja od 2026-09-06.licences: Različica 2026-09-14. Velja od 2026-09-14.
This file is the version history of every public legal document Stampomat publishes. One row per document per published version, newest first, with the effective date and a one-line summary of what changed. The public "Document versions" page at /{locale}/legal/changelog renders from this file.
The file doubles as evidence. Together with the legal_acceptances table, which stores the document, version, locale, surface and content hash for every acceptance, it lets you show which text was in force on any given date.
Internal accountability documents (records of processing, runbooks, assessments, registers) are not listed here. Each carries its own version line and is tracked in git.
1. How versions work
1. A version is the ISO date in config('legal.versions') for that document. The version and the effective date are the same value; the tables below print it through the {legal.effective.<document>} token so this file cannot drift from config.
2. Document names below are the page slugs served at https://stampomat.com/{locale}/legal/{slug}. The English drafting sources map to them as follows: privacy-policy.en.md is privacy, terms-customers.en.md is terms, terms-merchants.en.md is terms-business, terms-partner.en.md is terms-partner, and dpa, cookies, delete-account, imprint and licences match their file names. The subprocessors page has no markdown source; it renders from config/legal.php.
3. The rows dated 1 July 2026 were seeded from the repository history when this file was created during the August 2026 legal checkup. The full texts of those versions remain in git history (docs/legal/ before commit b5afb4a1, the first-drafts commit; its pre-rebase id a9063ffc changed in the 2026-09-04 rebase).
4. A version records which text was published and when it takes effect. It is not a request to accept again. Since 2026-09-13 a customer or a business that accepted any earlier version of a document is not asked to accept it again when its date moves. The acceptance step appears only where no acceptance is on record (for a customer, for a business on the dashboard, for each person in the merchant portal) and to a customer signing in from a signed-out browser, and each acceptance names the version and the text it saw; a version moving brings the step back for nobody. A change reaches everybody else through the page, this file and, where the document promises one, an email. From the versions that retired re-acceptance on, each row says whether a notice was owed.
2. Versions introduced by the August 2026 checkup
All ten pages below are published together as one corpus. The three documents that existed before are full rewrites; the other seven are first publications. Effective dates come from config through the tokens shown.
Two rows below, terms-business and privacy, were amended on 2026-09-10, the day of the versions they describe, and no version moves for it. The removal flow shipped that morning with a suppression: where a member asked an organisation never to enrol them again, the officer could record it, and the platform then refused that address on the Add members form and on every join link, holding a one-way fingerprint of it without an expiry. The owner withdrew it the same evening, before any account had used it, so no fingerprint was ever written and nobody ever accepted a text describing one. The rows say what actually shipped. The duty itself is unchanged and is not the platform's: honouring a request never to enrol somebody again belongs to the organisation as controller of its own list, and it stays in terms-business section 8.3.
terms-business was amended a second time the same day, again with no version move, and for the same reason: the text describes what shipped on 2026-09-10 and benefit groups did not survive the day. Annex A.11's fair-use list no longer names them. Benefit groups were an organisation-defined filing label on a partner benefit; they were retired whole that evening, and the cap that governed how many an organisation could make was retired with the feature, so the list named a limit that no longer exists. This amendment only REMOVES an item from a list of restrictions. It imposes no new duty, narrows no right and takes nothing away from a business, so it is favourable on its face and engages neither the section 14 notice period nor a fresh acceptance. No business account had accepted any version of this text on 2026-09-10 in any case. What replaced groups is not a limit and does not belong in A.11: which membership level a benefit is held back for, which the same annex already covers under levels.
terms-business and dpa were amended on 2026-09-13, and no version moves for either, for the reason the amendments above record: the change is favourable on its face. The loyalty dashboard gained a third assignable role, management ("Vodstvo"), offered only to a membership organisation. It does everything the account owner can do inside that organisation and is refused exactly one act, renaming the account owner's own title, which is the only act in the product that names the owner at all. Section 5 point 3 of terms-business now lists three assignable roles instead of two and says which two are membership-only; Annex A.5 point 8 says a team member holding that role may also remove a member, where it previously named the account owner alone; dpa section 8.3 describes the same role among the access controls. Every one of those sentences GRANTS a business a control it did not have and imposes no duty, narrows no right and takes nothing away, so it engages neither the section 14 notice period nor a fresh acceptance. Nothing a MEMBER was promised changes either: the customer terms have never named which person at an organisation may end a membership, only that the organisation may, and section 9 of terms is untouched.
The same amendment CORRECTS one sentence that had become wrong in the other direction. Annex A.9 of terms-business and section 8.3 of dpa say who may export customer data. A draft of this change added the management role to both lists; it does not belong there and never did. The three CSV exports exist only on a stamps or points account and the management role is offered only at a membership organisation, so no management user can reach an export at all. Both sentences now say so explicitly rather than merely omitting the role, because the omission is the part a reader would otherwise have to work out from two other clauses.
terms, privacy, terms-business, dpa, cookies and terms-partner move for one reason: a new version of a document no longer asks anybody to accept it again. A person who has never accepted still sees the acceptance step, and it is still recorded with the version, the language, the screen and a hash of the text. A person who accepted any earlier version is not stopped again when a version moves, and a change reaches them by notice. Every re-acceptance sentence was conditional on a future change and none was pending, so nothing anybody held moved. In the customer terms the click came after the 30 days had already run and never decided whether a change bound anybody, and what decides that (the email, the 30 days, the old version meanwhile, the free exit, no retroactive change) is unchanged word for word. The business terms already applied a new version to a business that keeps using the platform after the notice period, so removing the gate is solely in a business's favour under section 14 point 5; the DPA changes only by direct notice. Unlike the amendments above, the versions move: a new date no longer costs anybody a fresh acceptance, so rule 5 of section 4 is kept.
The notice owed was decided before publication from the acceptance records in both production databases; the counts and the decision are recorded in docs/legal/evidence/2026-09-14-no-regate-notice.md. Customers: a minor change under section 21 of terms, because it imposes no duty, narrows no right and takes nothing away, so terms, privacy and cookies take effect on publication and no email was owed; the privacy policy and the cookies notice are information, and nobody accepts them. Replacing an express click with continued use after notice could be read as affecting rights; counsel is asked to confirm this classification (lawyer-review-checklist.md section 2.2 point 4), and a precautionary 30 day email to wallet holders was drafted and was not sent. Businesses: the change is solely in a business's favour, but dpa section 14 changes the DPA only by direct notice, never by publication alone, and gives at least 15 days for a change that is not material, with no exception for a favourable one; and one business account outside the operator's own test accounts had accepted an earlier version. That business was not emailed. The platform had not yet opened to businesses and customers generally, and the operator gives that business direct notice personally and asks it to agree that the new versions apply at once, so terms-business and dpa take effect on publication, 2026-09-14. If it does not agree, the text it accepted applies to it until fifteen whole days have run after that notice, and it may end the agreement with immediate effect. The same notice covers the 2026-09-13 amendment above, which went out without one: that paragraph stays as written under rule 2 of section 4, and its reading that no notice period was engaged does not hold for the DPA, which has no exception for a favourable change. Benefit providers: the only terms-partner acceptance on record is the operator's own test account, so no email was owed and it takes effect on publication.
privacy moves from 2026-10-14 back to 2026-09-14, and the wallet language paragraphs take effect on publication. They add how the wallet chooses its language (section 4.1, Your language) and say that stampomat.com picks the language it opens in from the country of the IP address, which the site already did (section 3, Language). They first went out on 2026-09-13 at 23:50 (Ljubljana) in a version dated 2026-10-14, because the owner had judged the change material and planned a 30 day email to every wallet account holder, with the code switched off until then. On 2026-09-14, before any email was sent, the owner decided that none of the 25 wallet accounts with an email address belongs to a real customer: they are the owner's own accounts, test accounts and friends' accounts. So no notice is owed, the same finding as section 0 of docs/legal/2026-09-10-membership-removal-change-notice.md; the paragraphs take effect on publication, the language rule (WalletLanguageRule) is switched on the same day, no email was sent, and the 2026-10-14 date, which never took effect, is withdrawn. The version of 2026-09-14 in the row below is the same text without the two paragraphs; an acceptance names which text it saw through its content hash. The headcount, both decisions and the checks made are recorded in docs/legal/evidence/2026-09-13-wallet-language-notice.md. From this change on, the privacy rows carry their dates literally, because the privacy effective-date token prints the current version.
terms, privacy, cookies, delete-account, imprint and licences move because Stampomat is web-only for now. On 2026-09-13 the owner decided there is no Android app until one is built from scratch, and on 2026-09-14 the code of both Android apps was removed: the customer app com.stampomat.app, a Trusted Web Activity around the wallet that was never listed on Google Play (the site's /.well-known/assetlinks.json never named a signing certificate), and the counter tablet app com.stampomat.till, which was never installed on a tablet. These six pages stop describing them. No data is collected, kept or shared differently, no right or obligation changes, and nobody was ever offered either app, so each change is minor or informational and no notice was owed to anybody; that finding does not rest on the headcount above. delete-account, imprint and licences take effect on publication, 2026-09-14. terms, privacy and cookies had already been published under 2026-09-14 that same day, so by the owner's decision they carry 2026-09-15 rather than a second text under one date, and the versions of 2026-09-14 apply until then. The terms version also adds one sentence to Shop credit in section 6, saying that the app shows it as cash-back and never pays it out in cash, which the owner agreed on 2026-09-13 to add at the next change of these terms; it changes nothing about how credit works. The effective-date token prints a document's current version, so from this change on the rows of these six documents carry their dates literally, and the date cells of their earlier rows now show the date each of those versions took effect, taken from the history of config/legal.php. No other cell and no summary of an earlier row changed.
cookies and privacy were amended on 2026-09-14, the day their 2026-09-15 versions were published and before either took effect, and no version moves for either: they now describe Remember my details on this device at the checkout of business websites, which was switched on that day. It is storage that needs consent, and consent is asked by a box that starts unticked, before anything is stored. The email to account holders that section 17 of privacy and section 12 of cookies describe was not sent: no real customer had yet used a wallet or ordered from a business website, and the operator decided that the feature goes live at once. The decision is recorded in docs/legal/evidence/2026-09-14-remember-me-switch-on.md.
dpa moves, and terms-business, terms and privacy were amended on 2026-09-14, the day their 2026-09-15 versions were published and before any of them took effect, with no version move for those three, because Google Wallet passes are on by default. On 2026-09-09 every organisation was switched on and on became the default for new ones, because with the switch off by default members were shown a save button that ended on Google's error page. The texts still said that an organisation opts in to passes or has switched them on. They now say passes are on for every organisation unless it asks us to switch them off; only we can switch them off, from our own console. The same paragraphs stop saying that a card image goes to Google: since the pass was redesigned, points, level and member number travel as fields on the pass, and only a pass saved in the earlier design can still carry the address of that image, which is why the warning about the address stays and now says so. No new data is collected, no recipient is added and nobody is asked to accept anything again. The owner decided on 2026-09-14 that these texts take effect at once; the counts, the decision and the direct notice to Globallis are recorded in docs/legal/evidence/2026-09-14-wallet-default-on.md.
terms-partner, delete-account and imprint move, and privacy, cookies, terms, terms-business and dpa were amended on 2026-09-14 before their 2026-09-15 versions took effect, with no version move for those five, because the benefit provider pages changed on 11 September 2026 and the texts still described what was removed: a provider sign-in and dashboard, colleague invitations, voiding records and messages to members. A provider now answers an organisation's letter with Accept or Deny, checks members with codes or on a scanning page, and sees its figures on a private usage link. Pressing Accept agrees to the Partner Terms again and is recorded, and a provider record that no organisation names any more is deleted. The only benefit provider and the only acceptance of the Partner Terms on record are the operator's own tests, so no email was owed; the counts and the decision are recorded in docs/legal/evidence/2026-09-14-provider-terms.md.
privacy was amended on 2026-09-14, the day its 2026-09-15 version was published and before it took effect, with no version move, because customer groups changed that day. Section 4.14, What we record, now names every fact the group history holds: when a group was created and when it closed, who invited whom, joins, leaves, removals and changes of owner, each with its date, kept for the life of the group. If you delete your account now says that a group you created which still has other members passes to the member you choose on the delete page, and to its most active member only when an account is deleted without that choice, for example on a request to us; that a group you were alone in dissolves; and that your account link comes off the group's history as it comes off the ledger. Each of these facts was already recorded before this change, on the group's seats, on the group itself (including whom a group passed from) and in the security log; what is new is that a change of owner is kept with the group for the life of the group, and no longer only in the security log's 90 day window. The deletion sentence gives a customer a choice the automatic rule used to make for them and takes nothing away. No new category of data is collected, no recipient is added and no purpose changes. So the change clarifies records already kept and adds a choice in the customer's favour: it is not material, it takes effect on publication, and no email was owed. Whether keeping changes of owner for the life of the group is a lengthened retention that makes it material is put to counsel (lawyer-review-checklist.md section 2.1 point 11). The version does not move, for the same reason as the amendments above: the 2026-09-15 version had not yet taken effect, and a second text under 2026-09-14 is what the owner decided against.
privacy was amended a second time on 2026-09-14, the same evening, before its 2026-09-15 version took effect, with no version move, because shops started to see the history of the groups their customers are in. Section 4.14 gains What a shop sees: a shop sees the groups its own customers are or were in and the groups whose points, stamps or till slips it holds, with each group's number, status, owner, seats taken and history, and which group each of its customers is in now. It names only the members who are its own customers and shows everyone else without a name. A shop is a new recipient of this data, so this is a material change, which section 17 announces by email to account holders 30 days before it takes effect. No email was sent, and the change took effect on publication: no real customer or real business used the stamps or points side of the platform, where groups exist, and the operator decided on 2026-09-14 that the shop view goes live at once. The only real business on the platform runs a membership organisation, where groups do not exist and no shop view is shown. The decision is recorded in docs/legal/evidence/2026-09-14-group-history-for-shops-switch-on.md, and the questions for counsel in lawyer-review-checklist.md section 2.1 point 12.
privacy, terms, terms-business, terms-partner and delete-account move to 2026-09-23, and all five take effect on publication, because a security review of the platform changed how some things work, and the texts now say what the product does. Groups can pass on more than once, and only to a member who still uses Stampomat; the scanning page link of a benefit provider can be replaced; the reason an organisation gives for removing a member leaves our records after 7 days, as the texts already said, now also from our audit trail; emails to customers and members are no longer copied to our support mailbox; a deleted account is written down outside the database for 15 days so that restoring a backup cannot bring it back; there is no longer a reward code to type; and the business terms no longer say stamps can be collected by typing a code the shop shows. The notice decision: by the owner's decision under section 3.3 of our change procedure, taken before the platform opens to merchants and customers generally, these versions take effect on publication. The one business account that accepted an earlier version, Globallis, is not sent a separate notice, by the owner's decision of 24 September 2026: none of its members use the platform yet, and the owner works with it directly. The reasoning, the recipients and the notice are recorded in docs/legal/evidence/2026-09-23-security-audit-alignment.md. Nobody is asked to accept anything again.
| Document | Effective | Locales | Summary |
|---|---|---|---|
privacy | 2026-09-23 | en, mk, sl, de | Section 4.14, groups: a group passes from its owner, not its creator, to the most active member who has used Stampomat in the last 90 days, and stays as it is if nobody has; the previous owner can take it back within 14 days of being told, and once those days have passed the group can pass on again the same way. Section 4.11: the manual code lock covers typed stamp codes, a typed stamp code works only at its own shop, and there is no reward code to type. Section 4.7: emails we send to you as a customer or member are not copied to our support mailbox. Section 6.7: an organisation can replace a benefit provider's scanning page link, which ends the old link and signs out every device. Sections 12 and 14: when an account is deleted we keep, outside the database, its account number, a one-way fingerprint of its email address and the time, for 15 days, one day longer than our backups, only to run the deletion again if a backup taken before it is restored; basis: our legal obligation. Section 4.14: a group you own, not only one you created, passes on when you delete your account. |
terms | 2026-09-23 | en, mk, sl, de | Section on groups: the group's owner is the person who created it or the member it has since passed to; the owner removes members; if the owner stops using Stampomat for a long period, the group passes to its most active member who still uses Stampomat, and can pass on again later the same way. |
terms-business | 2026-09-23 | en, mk, sl, de | Section 1, Stamps mode: customers collect stamps by scanning a QR code at your counter. The text no longer mentions typing a short manual code you show them, which no screen has offered since June 2026. |
terms-partner | 2026-09-23 | en, mk, sl | Section 8: the organisation can replace the address of your scanning page. The old address then stops working, every device signed in to the page is signed out, and the new address serves every organisation that named you; you receive it in the instructions letter the organisation sends again. A printed code still cannot be changed in the product. |
delete-account | 2026-09-23 | en, mk, sl, de | Section 6: a note of your deletion kept outside the database (your account number, a one-way fingerprint of your email address and the time), kept 15 days, one day longer than our backups, and used only to run your deletion again if we restore a backup taken before it; the summary table lists it. Emails we send to you as a customer or member are never copied to our support mailbox. |
terms | 2026-09-18 | en, mk, sl, de | Section 13, Messages from shops: joining an organisation now works the other way round from signing in at a shop. On an organisation's join screen you choose whether to receive its messages, and if you leave that box empty the organisation sends you none. Nothing changes for anybody who already joined, and nothing changes for messages from a shop where you collect stamps or points. It asks nothing new of you and takes nothing away, so it is a minor change under section 21, effective on publication, and no email was owed. |
privacy | 2026-09-18 | en, mk, sl, de | Section 4, News and offers from a shop: an organisation writes to its members on your consent, given on its join screen, and nothing is sent unless you give it. The soft opt-in the shop paragraph rests on needs a contact obtained in the course of a sale, and joining an organisation is not a sale, so assessment 7 in the legitimate-interest assessments no longer carries memberships. This narrows what may be sent and adds no category of data, no recipient and no purpose, so it is not a material change and no email was owed. A shop where you collect stamps or points is unchanged, and so is the refusal offered at sign-in. |
privacy | 2026-09-15 | en, mk, sl, de | Amended a second time on 2026-09-14 before this version took effect, with no version move. Section 4.14 gains What a shop sees: a shop sees the groups its own customers are or were in and the groups whose points, stamps or till slips it holds, with each group's number, status, owner, seats taken and history, and which group each of its customers is in now; it names only members who are its own customers, and everyone else appears without a name. A shop never sees a member's email address, seat name or totals, or what the group holds at other shops. Basis for what a shop sees: our legitimate interest, and the shop's, in letting a shop understand who shares the balance it honours at its counter. A new recipient, so a material change; no email was sent, because no real customer or business used the stamps or points side of the platform, and the operator decided that it takes effect on publication. |
privacy | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 4.14, What we record: we also record when a group was created and when it closed, and every change of owner, each with its date, and keep the group's history for the life of the group. If you delete your account: a group you created that still has other members passes to the member you choose on the delete page, and to its most active member only when an account is deleted without that choice, for example on a request to us; a group you were alone in dissolves; your account link comes off the group's history as well as the ledger. No new category of data, no new recipient and no new purpose. Not a material change, so no notice was owed. |
terms-partner | 2026-09-15 | en, mk, sl | Rewritten to describe benefit providers as the product works now. You answer an organisation's letter with Accept or Deny; a benefit created with your address stays switched off until you accept; pressing Accept agrees to these terms and we record it. Sections 3 to 5 describe what we hold, how members are checked (the member's card, a code on the member's pass, or your code), the scanning page with its Google sign-in and 90-day cookie, and the private usage link; section 9 says we delete your provider record at the latest 90 days after no organisation names you, or within 30 days of your request, and that end-date letters stop once you say no. The provider area, colleague invitations, voiding records and messages to members are no longer described, and the old section 6 on messages is gone, so later sections are renumbered. |
privacy | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 4.9 describes benefit providers as they work now: a provider learns whether you are entitled to a benefit at that moment and which benefit, sees counts and recent times, and never gets your name, email address or member number; providers cannot write to you, and a use can no longer be voided. New section 6.7 tells benefit providers what we hold about them, that pressing Accept is recorded, how the scanning page's Google sign-in and its 90-day cookie work, that end-date letters stop once a provider says no, and that a provider record is deleted at the latest 90 days after no organisation names it, or within 30 days of a request. Sections 1, 2, 4.4, 4.7, 4.12, 6.2, 10, 11, 15 and 16 no longer describe a partner portal, partner staff accounts, partner messages or partner marketing consent. No new data about members. |
cookies | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Benefit providers: section 1 no longer names a partner portal, and section 4 replaces the removed partner_remember cookie (400 days) with benefit_station_remember, which keeps a benefit provider signed in to its scanning page on its own device for 90 days, is renewed at each sign-in and is removed on sign-out. |
terms | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 10, Benefits from partner businesses, describes how a benefit is checked now (your pass, a short-lived code on your pass, or the partner's code) and what the partner learns; a use can no longer be voided, and partners cannot send you messages through Stampomat. Sections 9 and 13 no longer mention an agreement to hear from partner businesses or partner messages. Nothing new is asked of you. |
terms-business | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 1 point 5 and Annex A.6 describe benefit partners as they work now: an invitation letter with Accept and Deny, a benefit created with an address switched off until the partner accepts, pressing Accept agreeing to the Partner Terms and being recorded, the ways of checking a member, the scanning page and the private usage link. The partner portal, partner messages and partner marketing, removed on 11 September 2026, are no longer described in section 6.1, Annex A.5, A.6 or A.11. No obligation is added. |
dpa | 2026-09-15 | en, mk, sl | Amended on 2026-09-14 before this version took effect, with no version move. Sections 1.1, 1.3, 2.1, 6.4 and 6.8 no longer describe partners holding accounts, voiding redemptions or partner marketing, all removed on 11 September 2026: a partner checks members, records redemptions and sees its usage figures, and accepts the Partner Terms by pressing Accept, which we record. No obligation is added. |
delete-account | 2026-09-15 | en, mk, sl, de | Section 12, benefit partners: a partner has no account with us; we say what we hold, that the record is deleted automatically once no organisation's benefit names the partner (at the latest 90 days later) or by hand within 30 days of a request, and what stays with the organisation. Sections 1, 5, 8 and 13 no longer mention partner accounts, partner team members or partner marketing consents. |
imprint | 2026-09-15 | en, mk, sl, de | Section 2 names the pages benefit partners use to answer an invitation, scan members and see how a benefit is used, instead of the benefit partner portal removed on 11 September 2026. |
privacy | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 5, How long, for orders from business websites: a reason the business wrote in its own words for declining or cancelling your order is now removed together with your name, phone number and email address, 90 days after the order was completed, declined or cancelled; a standard reason, chosen from a list or given by an automatic decline, stays. The retention table says the same. This removes more data and adds none. |
terms-business | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Annex B point 3 said the menu and checkout show customers the allergen notice with your phone number; it now describes how the notice appears: a short line on each dish of the menu, repeated at checkout with your phone number when you have given one. No obligation changes. |
privacy | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 5, Order emails: a customer who ordered from a business website is now emailed when the business accepts the order (the confirmation, with a link to follow it) and only if the order does not go ahead (declined, not answered in time, or cancelled by the business). The order placed, ready for pickup and own-cancellation emails described earlier the same day are no longer sent: the order status page shows receipt at once and every later state live. No new data, no new purpose, fewer messages. No email was owed, because no real customer had yet ordered from a business website. |
dpa | 2026-09-15 | en, mk, sl | Section 7.3 said Google acts as a sub-processor "when an organisation opts in to Google Wallet passes". Since 2026-09-09 passes are on for every organisation, so it now says they are on for your organisation unless you ask us to switch them off, and that we create a pass object at Google only while they are on and a member asks. What is sent to Google and when a pass is expired are unchanged. The DPA changes only by direct notice: the operator gives it to Globallis, the one business account outside the operator's own that had accepted an earlier version, and asks it to agree that this version applies at once; if it does not, the text it accepted applies to it until the notice period in section 14 has run. Whether an on-by-default sub-processor needed the notice and objection window of section 7.2 is a question for counsel (lawyer-review-checklist.md section 2.5). |
terms-business | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, joining the Annex B change of the same version, with no version move. Annex A.12 point 1 said membership passes can be saved to Google Wallet "when we have enabled Wallet for your organisation". It now says Google Wallet is on for every organisation unless you ask us to switch it off, and that while it is on your members can save their passes, which is how the platform has worked since 2026-09-09. Point 2 no longer says a pass shows a card image: the member's points, level and member number are fields on the pass. A pass object is still created only when a member asks. Notice: the operator tells Globallis directly, as for dpa, instead of the email in section 14 point 1. |
terms | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 11 said you can save your pass to Google Wallet "if your organisation has switched this on"; it now says Google Wallet is on for every organisation unless it asks us to switch it off, which is how the product has worked since 2026-09-09. It also no longer says we send Google the address of a card image: your points, level, member number and QR code travel as fields on the pass. Saving stays optional and a pass is still created only when you ask. It imposes no duty, narrows no right and takes nothing away, so a minor change under section 21 and no email was owed. |
privacy | 2026-09-15 | en, mk, sl, de | Amended on 2026-09-14 before this version took effect, with no version move. Section 4.4 said Google Wallet passes apply "if your organisation has enabled" them; it now says they are on for every organisation unless it asks us to switch them off, as they have been since 2026-09-09. The list of what we send Google no longer includes the address of a card image, because points, level, member number and the QR code are fields on the pass; the warning about the card image address now says it concerns a pass saved in the earlier design, which can still show that image. No new data is collected and no recipient is added. Information, not an agreement, so no notice was owed. |
terms-business | 2026-09-15 | en, mk, sl, de | Annex B, allergens. Point 2 no longer asks you to declare the fourteen allergen groups for every menu item on the platform, which the platform never let you do: you warrant that you give order customers the allergen and ingredient information food law requires of you, in the way the law allows for your premises, and keep it current. Point 3, Allergen display, becomes No allergen display: the site shows no allergen or ingredient information and never has; the menu and the checkout show customers a notice to ask you about allergens before they order, with your phone number when you have given one, and that notice does not replace your duty as the food business operator. Sections 12.2 and 12.4, which keep allergen data yours and cover claims about it, are unchanged. Effective on publication with no notice period: no business outside the operator's own had used Sites, and on 2026-09-14 the operator decided to apply every change before the first real merchant and its customers join (docs/legal/evidence/2026-09-14-allergens-annex-b.md). |
privacy | 2026-09-15 | en, mk, sl, de | Section 5, orders from business websites. Who sees your order: the business's email copy goes to its order notification address or, when none is set, to the people who manage its site, and carries your name, phone number and, if you gave one, your email address. Order emails: you are emailed when the order is placed, accepted, ready for pickup, declined, not answered in time, or cancelled by you or by the business; a reply reaches the business; a record of which emails went out and when is kept, without content or address. The acknowledgement and the accept or decline emails were already described but had never been sent, because they waited in a queue nothing processed; every order email now goes out when its change happens; the automatic decline, its email and the business reminder run from the scheduler, installed in production right after the Sites release. No new data, no new purpose and no new kind of recipient. Notes and allergies no longer says the menu shows allergen information for each item, which business websites do not do; it says to ask about allergens before ordering. Added on 2026-09-14 to this version, which was published earlier that day and had not yet taken effect, so the version does not move; no email was owed, because no real customer had yet ordered from a business website (docs/legal/evidence/2026-09-14-remember-me-switch-on.md, section 3). |
cookies | 2026-09-15 | en, mk, sl, de | Remembered checkout details on business websites. Section 9 lists the new item: only if you tick Remember my details on this device at the checkout of a business website are your name, phone number and email address kept in that browser's local storage (stampomat_checkout_details_ followed by the site id), for that site's address only, with a copy in that tab's session storage (stampomat_checkout_pending_ followed by the site id) until your order status page opens. Notes and pickup time are never saved, nothing reaches our server except as part of an order you place, the details are used for up to 365 days after they were last saved, and Not you? Clear removes them. Section 7 now names two exceptions to "no script on a business website writes to browser storage", section 2 names two exceptions you control, section 3 says each of the two asks for consent where it is used, and section 11 says what clearing the item does. This is storage that needs consent, and consent is asked by a box that starts unticked, before anything is stored. Section 12 says account holders are told by email of such a change; no email was sent, because on 2026-09-14 no real customer had yet used a wallet or ordered from a business website, and the operator decided the feature goes live at once (docs/legal/evidence/2026-09-14-remember-me-switch-on.md). Added on 2026-09-14 to this version, which was published earlier that day and had not yet taken effect, so the version does not move. |
privacy | 2026-09-15 | en, mk, sl, de | Section 5 gains Remembering your details: at the checkout of a business website you can tick Remember my details on this device, and only then are your name, phone number and email address saved in that browser, for that site's address only and never on our server, for up to 365 days after they were last saved. Not you? Clear, an order placed unticked with the same details, or clearing the site's data removes them. Basis: your consent. Section 13 says this is the one item in browser storage that holds personal data, and section 15 adds Not you? Clear to the ways to withdraw consent. Nothing new is collected on our server and there is no new recipient. Section 17 promises account holders an email at least 30 days before a material privacy change; no email was sent, for the reason in the cookies row above. Added on 2026-09-14 to this version, which was published earlier that day and had not yet taken effect, so the version does not move. |
terms | 2026-09-15 | en, mk, sl, de | Section 1 no longer lists the Stampomat Android app among the places these terms cover, and section 23 no longer grants a licence to use it: Stampomat is web-only for now, and the app was never listed on Google Play or offered to anyone. Shop credit in section 6 gains one sentence: the app shows shop credit as cash-back, and it is never paid out in cash, which is the word the app has used since 2026-09-13 and changes nothing about how credit is earned, spent or refunded. A minor change under section 21, because it imposes no duty, narrows no right a customer could use and takes nothing away, so no email was owed. Published on 2026-09-14; the version of 2026-09-14 applies until this date. |
privacy | 2026-09-15 | en, mk, sl, de | Section 1 no longer names the Stampomat app for Android (package name com.stampomat.app) among the services this policy covers; the wallet is at stampomat.com/app. No collection, purpose, recipient or retention window changed. Information, not an agreement, so no notice was owed. Published on 2026-09-14; the version of 2026-09-14 applies until this date. |
cookies | 2026-09-15 | en, mk, sl, de | The Stampomat Android app is no longer described: section 1 no longer lists it among the places stampomat.com storage is used, section 4 no longer says it uses the same cookies through Chrome and the till_device row no longer says a till app reads that cookie in a built-in browser view, and section 11 no longer mentions clearing storage for the app (clearing Chrome's stampomat.com entry on Android still does the same). No cookie or storage item was added, removed or changed. Information, not an agreement, so no notice was owed. Published on 2026-09-14; the version of 2026-09-14 applies until this date. |
delete-account | 2026-09-14 | en, mk, sl, de | The introduction no longer names the publisher as the developer of a Stampomat app on Google Play, section 1 no longer mentions the Android app, section 2 drops the sentence about uninstalling it, and section 3 now says the app is the wallet at stampomat.com/app before the same steps. Nothing about what is deleted, what is kept or when it happens changes. A description, not a contract, so no notice was owed. |
imprint | 2026-09-14 | en, mk, sl, de | Section 2 no longer lists the Stampomat app for Android or says who would be named as its developer on Google Play; the loyalty service is described by the website, the wallet at stampomat.com/app and the rest of the list, unchanged. Provider identification, supervisory bodies and contacts are unchanged. No notice was owed. |
licences | 2026-09-14 | en, mk, sl, de | Section 9, The Stampomat Android apps, is removed together with the Android libraries it listed (Android Browser Helper, AndroidX, the Kotlin standard library and ZXing core), because neither app is distributed; sections 10 to 14 become 9 to 13 and every cross reference follows. The introduction and the section on other Stampomat products now cover stampomat.com only, section 2 no longer says the Android apps show the same pages, and section 1 no longer names Google Play among Google's trademarks. Nothing served to a browser changed. No notice was owed. |
privacy | 2026-09-14 | en, mk, sl, de | Section 4.1 gains Your language: a language the customer chooses in the wallet's menu or on the sign-in screen wins over everything; until then the wallet follows the country of the IP address, looked up on each visit in a database on our own server, with the IP address neither stored for this nor sent to a geolocation provider and only the country and a one-way hash of the address kept in the session, which is deleted about two hours after the last request; then the language last shown, then the browser's; the page before signing in after a scan is in that shop's language; the language last shown and the time a language was chosen are kept so that emails follow them. Section 3 Language now says that opening stampomat.com without a language cookie picks the language from the country of the IP address in the same way, which the site already did. Basis for both: legitimate interest. No new recipient, no new retention window, and nothing leaves our server. Published overnight on 2026-09-13 in a version dated 2026-10-14; effective on publication from 2026-09-14, because no wallet account belongs to a real customer, so no notice was owed and no email was sent. |
terms | 2026-09-14 | en, mk, sl, de | A new version no longer brings the acceptance screen back. Section 2 now says a later version never brings the acceptance screen back or asks you to accept again. Section 21 no longer says the app asks you to accept a new version when it takes effect: you do not need to do anything, and a material change applies to you once its 30 days have run if you keep your account. The email, the 30 days, the old version meanwhile, the free exit before and for 30 days after, and no retroactive change are unchanged. A minor change under section 21, so no email was owed. |
privacy | 2026-09-14 | en, mk, sl, de | Section 17 no longer says wallet holders are asked to confirm a new version at their next sign-in: you confirm you have read this policy when you sign in, and a new version never asks again. A material change is still emailed to account holders at least 30 days before it takes effect. No collection, purpose, recipient or retention window changed. Information, not an agreement, so no notice was owed. |
terms-business | 2026-09-14 | en, mk, sl, de | Section 2 point 7, Re-acceptance, becomes Later versions: the gate appears only to an account that has never accepted, once for a business on the dashboard and once for each person in the merchant portal, and a later version of these terms or the DPA does not bring it back. Section 14 point 3 no longer names acceptance at the gate: a new version applies if you keep using the platform after its notice period, and you may still end the agreement with immediate effect before it takes effect. Solely in a business's favour under section 14 point 5, which still requires the notice of section 14 point 1. The one business account outside the operator's own that had accepted an earlier version was not emailed: the operator tells it directly and asks it to agree that this version applies at once, and this version takes effect on publication together with the dpa. |
dpa | 2026-09-14 | en, mk, sl | Section 1.2 no longer says the acceptance page returns when a new version needs acceptance, and section 14 no longer says the dashboard or portal asks for it at the next sign-in: a later version does not bring that page back and reaches you by the direct notice section 14 already required, never by publication alone. The first-use acceptance page still never blocks the legal pages, sign-out or the deletion routes. Not a material change, so section 14 requires direct notice with at least 15 days unless the business agrees to less: the operator gives that notice directly to the one business account outside its own that had accepted an earlier version, rather than by email, and asks it to agree that this version applies at once, so it takes effect on publication. The same notice covers the 2026-09-13 management role amendment. |
cookies | 2026-09-14 | en, mk, sl, de | Section 4 said the customer_remember cookie does not skip the acceptance screen when the terms or the privacy policy change, so you would be asked once more. A change no longer brings that screen back; the item now says the cookie never stands in for a first acceptance. No cookie or storage item was added, removed or changed. Information, not an agreement, so no notice was owed. |
terms-partner | 2026-09-23 | en, mk, sl | Section 2 no longer says that a person added later accepts at first sign-in, or that the provider area asks for each new version to be accepted before you continue, and section 13 no longer says the provider area asks you to accept a new version. The provider sign-in and its terms gate were retired on 2026-09-11. The notice periods in section 13 are unchanged. The only acceptance of these terms on record is the operator's own test account, so no email was owed and this version takes effect on publication. |
cookies | 2026-09-13 | en, mk, sl, de | The customer_remember row now describes a token per device. The cookie used to hold one token shared by every browser a customer had signed in on, so signing out anywhere signed them out everywhere; each browser now gets its own random 64-character token, of which the server stores only a one-way hash, and signing out ends that device's sign-in only. Deleting the account still signs out every device, as delete-account says. No cookie is added or removed, the name, lifetime and protections are unchanged, no new data is collected (no device name, user agent or IP is stored with the token), and the change only narrows what a sign-out takes away, so nothing needs consent and no acceptance is re-gated. |
delete-account | 2026-09-13 | en, mk, sl, de | The in-app path is corrected to the new wallet layout. The account menu now holds a single entry named Account, and it is that page that carries Delete account, Download my data and Unlink. The short version, the numbered steps in section 3 and the two Unlink sentences now say "account menu, Account, Delete account" and "the Account page" where they said "the account menu". Nothing about what is deleted, what is kept or when it happens changes, and the page remains a description, not a contract, so no acceptance is re-gated by this version. |
terms | 2026-09-10 | en, mk, sl, de | Material consumer change. Effective on publication rather than after the 30 day notice period section 21 describes: that period protects people who accepted an earlier version of this text, and on 2026-09-10 no customer account had. The procedure for the next material change, once real accounts exist, is docs/legal/2026-09-10-membership-removal-change-notice.md. Section 9 now states plainly the two things an organisation can do to a membership, and says that pressing the join button accepts both. The hold was never in these terms at all although the product has offered it since 2026-09-09: a hold deletes nothing, the member keeps their roster place and their points, cannot record attendance or use a benefit until it is lifted, is emailed at the start and at the end with the organisation's reason if it typed one, and a saved Google Wallet pass stays in the wallet, says PAUSED and carries that reason to Google. Removal is new to the document and new to the product: it deletes the membership, the attendance records, the organisation's private note and the partner marketing consent, on an active card or a held one alike; the pass stops working straight away and a saved Google Wallet pass is expired at once (Google permits expiring a pass, not deleting one, so it stays in the wallet as an expired pass until the member removes it); the member is emailed in the organisation's name; the member's Stampomat account and their cards at every other business are untouched and no organisation can ask us to delete those; the record of a benefit used stays without a name; and the organisation can undo the removal for 7 days. Section 16's closed list of grounds gains a sixth, "a membership ended under the organisation's own rules, as section 9 describes", and section 9 states expressly that such an ending is not a removal of points under section 16 and that the points earned stay in the organisation's totals with the member's name taken off them. Nothing was removed from section 16's five existing grounds. Section 11 is corrected to say that a Wallet pass is expired straight away and not deleted, and that a held card's pass shows the hold. |
terms-business | 2026-09-10 | en, mk, sl, de | Material business change. Effective on publication rather than after the 30 day notice period section 14 describes: that period protects people who accepted an earlier version of this text, and on 2026-09-10 no business account had. The procedure for the next material change, once real accounts exist, is docs/legal/2026-09-10-membership-removal-change-notice.md. Annex A.5 point 7 gains the hold: the one adjustment that stops a card working and the only one that lifts again, with the two letters we send in the organisation's name and the reason shown on the card and on the Google Wallet pass, and a pointer that this control, or the Alumni status, is what "not for now" means. Annex A.5 point 8 (Removal) is expanded from two sentences to a full clause: it works on an active membership and on a held one, only the account owner may do it, and it names what is deleted, what is anonymised (the attendance points, which stay in the organisation's own totals without the member's name), what stays (redemption counts without a name, and the member's own wallet account, which is never the organisation's to delete), that we email the member in the organisation's name and that letter cannot be switched off, that a removal can be undone for 7 days, that a finished season's leaderboard and podium are recalculated without a removed member, and that a removal is not a hold. Annex A.5 point 2 records that the customer terms now make the member accept both acts at joining, and that this acceptance covers the platform side only and displaces no notice, ground or appeal that the organisation's own statutes or national law owe a member it suspends or expels. Section 8.3 gains a duty to honour a member's request never to be enrolled again, which is the organisation's own to keep and which the platform does not enforce for it; the sensitive-data duty extends to the reason typed at a hold and at a removal, both of which the member reads. Annex A.11 names the daily removal limit and says an undone removal still counts against the day. Amended later the same day, with no version move: Annex A.11 no longer lists benefit groups among the capped items, because the feature and its cap were retired that evening. The amendment removes an item from a list of restrictions and adds nothing, so it takes no right away from a business. |
privacy | 2026-09-10 | en, mk, sl, de | Section 4.3 already said membership records are kept "until the organisation removes you"; it now describes both things an organisation can do. The hold is disclosed for the first time: what we record (that the card is on hold, when the hold started, and the reason typed for the member), the two emails, and the reason shown on the card. Removal is described concretely: that the member is emailed, what is deleted, what is anonymised into the organisation's totals without a name, what is kept without a name, and that the organisation can undo it for 7 days, for which we hold a copy of the deleted records and then destroy it together with the organisation's reason. Section 4.4 adds that a hold and its reason travel to Google in the pass, and that the Wallet expiry blanks the name, member number, pass text and barcode at Google in the same request and cannot delete the pass, so an expired pass stays in the member's Wallet. Section 12 gains two rows (the never-signed-in roster account record and its 7 day window, and the undo copy) and notes that a hold and its reason live and die with the membership record. No new collection, no window lengthened; the one new recipient disclosure is the hold reason reaching Google in a pass the member chose to save. |
delete-account | 2026-09-10 | en, mk, sl, de | Section 2 and section 8 add the third route by which a membership ends: the organisation removing you on its own initiative, on an active card or a held one, which is its decision and not a deletion of your account. Section 2 also names the hold and says it deletes nothing. Section 8 says what a removal takes and what it leaves, and adds that a roster-created account record for somebody who never signed in is deleted within 7 days after the removal once nothing refers to it, and that signing in with that address before then keeps it. Section 7 and the section 15 timetable are corrected on two facts: a Wallet expiry that Google refuses is retried every minute rather than every hour, and an expired pass stays in your Google Wallet until you remove it there, because Google permits expiring a pass and not deleting one. Section 15 gains a row for removal from a roster. |
dpa | 2026-09-10 | en, mk, sl | Material change, sitting with the business terms. Effective on publication rather than after the 30 day notice period section 14 describes: that period protects people who accepted an earlier version of this text, and on 2026-09-10 no business account had. The procedure for the next material change, once real accounts exist, is docs/legal/2026-09-10-membership-removal-change-notice.md. Section 2.1 adds placing and lifting a hold to the processing, adds the hold and the reason typed for the member to the data, names the organisation's own removal as a way a membership ends, and discloses the 7 day snapshot held so the removal can be reversed. Section 3.9 gains the mechanism behind a promise the document already made: we can place a legal hold on one membership that the organisation's removal route refuses, used while a request about that member is open; it is distinguished by name from the organisation's own hold on a card, and it touches nothing else. Section 5 records the symmetric duty to the enrolment notice: the hold, resume and removal letters are sent in the organisation's name, the removal letter tells the member their wallet account is untouched, and none of the three can be switched off. Section 6.8 states expressly that an organisation may hold and may end a membership it created, may not delete a member's wallet account, and that we will not execute an instruction to do so. Section 7.3 extends the Wallet expiry from "when the member's data is erased" to "or the membership ends", adds that the same call blanks the identifying fields at Google, records that a held card's reason travels to Google in the pass, and states that Google permits expiring a pass and not deleting one. |
licences | 2026-09-08 | en, mk, sl, de | Two removals, both of things that were never served to a reader's browser. The Leaflet row is removed. Its two files were present under /vendor/ but loaded by no page, which the row itself said; they were deleted from the server on 2026-09-08, so the notice no longer has a subject. Nothing else on the page changes: no library was added, upgraded or newly loaded, and every remaining row still names a file that ships. The paragraph listing seven development-only JavaScript packages (Tailwind, PostCSS, Autoprefixer, Vite, the Laravel Vite plugin, axios, concurrently) is rewritten in the past tense: the build configuration and its lockfile were deleted on 2026-09-08 because no page ever loaded the bundle, so the repository no longer carries a JavaScript build. Nothing that reaches a browser changed. |
privacy | 2026-09-06 | en, mk, sl, de | Section 11 named only Google and Cloudflare as certified under the EU-US Data Privacy Framework, which left our host, InterServer, resting on the standard contractual clauses bullet below it. InterServer's certification was verified active on the official participant list on 2026-09-06, and no standard contractual clauses are in place with them, so the sentence named the wrong safeguard. InterServer is now named among the certified recipients. No recipient was added or removed, nothing about the data, the purposes or the retention changed, and the safeguard itself was in force throughout. |
subprocessors | 2026-09-06 | en, mk, sl | InterServer row corrected against primary evidence obtained on 2026-09-06. Transfer mechanism becomes the EU-US Data Privacy Framework, verified active on the official participant list rather than taken from the vendor's own statement; the contract cell now names their terms of service, whose closing section is an Art. 28 data processing agreement accepted on use; the last verified date is filled in for the first time. No sub-processor was added, removed or given a new purpose, so the 15 days notice and objection window in dpa section 7.2 is not engaged. |
privacy | 2026-09-01 | en, mk, sl, de | Full rewrite: one policy for loyalty, Sites and Growth, sectioned by reader; adds Google Wallet passes, memberships and rosters, groups with member name visibility and owner succession, partner benefits and partner marketing, the Sites order and wallet link, the inferred city behind the wallet's Places to try ordering, business prospects and Instagram correspondents; retention table and recipient list render from config; contact mailbox becomes hello@stampomat.com. |
terms | 2026-09-01 | en, mk, sl, de | Full rewrite of the customer terms: points mode and vouchers, the groups clause (up to seven people share one balance, leaving leaves the points behind), memberships and passes, partner benefits, broadcasts and how to object, self-service deletion, consumer-safe liability with carve-outs, Slovenian law plus the sentence that consumers keep the mandatory protection of their country of residence, 30 days notice for material changes, minimum age 16, acceptance recorded by click instead of by use. |
terms-business | 2026-09-01 | en, mk, sl, de | Full rewrite of the business terms: one B2B document with annexes for Loyalty, Sites and Fees; joint controller and processor allocations per data flow; incorporates the dpa; liability cap with carve-outs; prize-game prohibition; 30 days notice for material changes and 15 days minimum otherwise; Slovenian law and Ljubljana courts; acceptance recorded at the dashboard gate instead of by use. |
terms-partner | 2026-09-23 | en, mk, sl | First version: short terms for benefit partners covering portal use, void rights, the data a partner sees at the door, marketing only with recorded member consent, and confidentiality. |
dpa | 2026-09-01 | en, mk, sl | First version: Art. 28 processor terms, Art. 26 joint controller arrangement with a responsibility matrix, sub-processor authorisation with 15 days change notice and objection right, security measures summary, breach notice to the business within 48 hours, deletion or return within 90 days of termination. |
subprocessors | 2026-09-06 | en, mk, sl | First publication: the sub-processor and recipient table (party, location, purpose, data, transfer mechanism, contract basis, last verified), rendered from config. |
cookies | 2026-09-01 | en, mk, sl, de | First version as its own page: the full storage table per product, why only strictly necessary storage is used and no banner is shown, the Google Maps two-click gate on Sites, and how the analytics beacon honours Do Not Track. |
delete-account | 2026-09-01 | en, mk, sl, de | First version: the in-app deletion path and the email path, what is deleted and what is kept (90 days of audit rows, invoices), timelines, Google Wallet pass expiry, and the app and developer named for Play and Meta reviewers. |
imprint | 2026-09-01 | en, mk, sl, de | First version: provider identification from config, supervisory bodies, the complaint statement (written answer within 15 days), the ADR statement, and the notice-and-action contact for illegal content. |
licences | 2026-09-01 | en, mk, sl, de | First version: third-party notices, including OFL font licences, the DB-IP database under CC BY 4.0, and bundled JavaScript libraries. |
3. Versions of 1 July 2026
The first published set. Three public documents, en, mk and sl views; the de locale existed on the site but had no legal text.
| Document | Effective | Locales | Summary |
|---|---|---|---|
privacy | 2026-07-01 | en, mk, sl | First policy: stamp-card wallet with Google sign-in, joint controllership with the shop for stamp activity, Stampomat sole controller for the account, operator named as an individual in Ljubljana, contact hello@stampomat.com. |
terms | 2026-07-01 | en, mk, sl | First customer terms: wallet, stamps and rewards; agreement stated as arising from signing in with Google and using the service. |
terms-business | 2026-07-01 | en, mk, sl | First business terms: loyalty program use, five listed customer data types under the joint-controller clause; acceptance stated as arising from use of the platform. |
4. Rule for adding entries
Follow this whenever a public document changes. It is step 4 of the update flow in README.md.
1. Bump the document's date in config('legal.versions') and add one row to the top of section 2 in the same commit: slug, the {legal.effective.<slug>} token, locales, and a one-line summary in plain language naming the substantive change, not the editing act. A guard test fails when a legal view changes without a version bump, so the row and the bump cannot be forgotten separately.
2. Never edit or delete an existing row. This file is evidence. If a row is wrong, add a new row that says so.
3. A version bump re-gates nobody. The customer interstitial appears only to a customer with no acceptance on record and to a customer signing in from a signed-out browser; the business gate appears only where no acceptance is on record, once for a business on the dashboard and once for each person in the merchant portal. A version moving brings either back for nobody. A change reaches people who accepted an earlier version by notice, sent by the operator: a material change of terms by email to wallet holders 30 days before the effective date; every change of terms-business or dpa by email to every business account that accepted an earlier version, 30 days before a material change and at least 15 days before any other; every change of terms-partner by email to the confirmed address of each benefit provider, 30 days before a material change and at least 15 days before any other; a material change of privacy by email 30 days ahead, for information. Say in the row which notice was owed.
4. A change to the sub-processor list is made in config, bumps subprocessors and gets a row here. Whether it also starts the 15 days notice and objection window depends on what changed, and dpa section 7.2 is the test: adding a new or replacement sub-processor, or giving an existing one a new purpose, starts the window; removing one is announced without a waiting period; correcting a transfer mechanism, a contract basis or a verification date on a party that is already listed changes no processing and starts nothing. Say in the row which of these it was.
5. Fixing a typo that changes no meaning in any language is still a new version. The acceptance record stores a content hash, so any change to the rendered text must map to a dated version.
6. New documents enter section 2 with a "First version" summary. A document that is retired gets a final row saying so and the view starts answering with a pointer to its replacement.