Document versions

Ta dokument je na voljo samo v angleščini.

Current versions

• privacy: Različica 2026-10-21. Velja od 2026-10-21.
• terms: Različica 2026-10-18. Velja od 2026-10-18.
• terms-business: Različica 2026-11-19. Velja od 2026-11-19.
• terms-partner: Različica 2026-09-23. Velja od 2026-09-23.
• dpa: Različica 2026-11-19. Velja od 2026-11-19.
• cookies: Različica 2026-10-21. Velja od 2026-10-21.
• delete-account: Različica 2026-10-12. Velja od 2026-10-12.
• imprint: Različica 2026-09-15. Velja od 2026-09-15.
• subprocessors: Različica 2026-10-12. Velja od 2026-10-12.
• licences: Različica 2026-10-13. Velja od 2026-10-13.

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.

privacy, terms-business and dpa move to 2026-10-02 and take effect on publication, because the team roles changed on 30 September 2026 and the texts now say what each role can do. Only the account owner adds, changes or removes team members. A membership organisation is offered management and operator, and no longer admin; an operator only scans members' cards at the active events assigned to them and sees nothing else of the dashboard. The same change corrects three sentences that were already wrong: dpa section 8.3 said admin users can do everything in your programme, though they have never managed the team; Annex A.8 of terms-business said admins and operators write private customer notes, though operators have never reached them; and the Macedonian and Slovene terms-business still named the management role among those who can export, which the English and German versions stopped doing on 2026-09-13 (English prevails for businesses). Nothing is collected, kept or shared differently, every change narrows who can do what, and nobody is asked to accept again. The owner decided on 2026-10-02 that these versions take effect at once, without the notice period section 14 of terms-business and section 14 of dpa describe and without a direct notice; the decision and its reasoning are recorded in docs/legal/evidence/2026-10-02-team-roles.md, and the question is on the counsel list (lawyer-review-checklist.md, L37).

cookies and licences move to 2026-10-07 and take effect on publication, because the Stampomat Counter app is distributed from stampomat.com. It is an Android app for the ZCS Z92, a counter device with a built-in printer: it opens the counter till in Chrome and prints the till's slips on that printer. licences gains a section listing what the app contains: its open-source libraries under the Apache License 2.0, each with its version and copyright notice, and the device maker's SmartPos SDK, proprietary software used under the maker's terms only to drive the printer. cookies lists the one item the till keeps in session storage inside the app, till-adopt-builtin-reloaded, which stops the page reloading in a loop after it switches the device to the built-in printer and holds nothing about anybody. Both pages are information, not agreements: nobody accepts them and nobody is asked to accept anything again. Nothing personal is collected, kept or shared differently, so the change is not material and no email is owed under section 12 of cookies; the reasoning is recorded in docs/legal/evidence/2026-10-07-counter-app-and-till-storage.md.

privacy, terms, delete-account, cookies, licences, subprocessors, dpa and terms-business move to 2026-10-08 and take effect on publication, because a membership pass can now be added to Apple Wallet, and every text that names Google Wallet says what Apple Wallet does. Where a card offers Add to Apple Wallet and the member taps it on an iPhone, we build the pass and send it straight to their device. Before the pass is added, the pass page asks for the member's explicit consent to sending the device's push token to Apple Inc. in the United States, which no adequacy decision and no other safeguard covers, and records when it was given; removing the pass from every device that holds it, or writing to us, withdraws it, and adding the pass again asks again. We keep a record of the pass and, for each device that added it, an identifier and the push token Apple issued to it. To keep the pass current we send Apple only that push token and an empty message addressed to our pass type, and the phone then fetches the pass from us. When the membership ends we void the pass at once, the phone shows it as void once it fetches the update, and its records go 30 days later. Apple Inc. joins the recipients as the push service of the member's device, not as a sub-processor, the same position as the browser push services in section 7.4 of dpa; the right to object in dpa section 7.2 concerns sub-processors. Apple Wallet follows the same switch as Google Wallet, and until it opens to members only the operator's own test account can add a pass. The change is not material for members, because nothing changes for anyone who does not add an Apple Wallet pass, so no email goes to account holders. The owner decided on 2026-10-08 that these versions take effect at once, without the notice period section 14 of terms-business and section 14 of dpa describe, without a direct notice, and without the announcement at least 15 days ahead that privacy section 10 and the sub-processors page describe for a new recipient. Nobody is asked to accept again. The decision, its reasoning and the evidence are recorded in docs/legal/evidence/2026-10-07-apple-wallet.md (decision D13), and the questions are L39 and L40 in lawyer-review-checklist.md.

privacy, cookies and licences were amended on 2026-10-08, the day their 2026-10-08 versions were published, with no version move, because the Apple Wallet consent is asked on a short screen that opens from the badge instead of a box beside it. On the pass page, tapping Add to Apple Wallet opens a short screen that says what is sent, to whom and where, that no adequacy decision or other safeguard covers it, and that it is not protected there as in the EU; the member agrees by tapping I agree and add, or closes it with Not now, which records nothing. privacy section 11 says so and states the risk of the transfer in its own words; cookies section 4 says that until the member has consented the badge first opens that screen on the same page and the answer reaches our server before the download; licences section 6 says that an email badge leads to the pass file or first to the consent screen. Nothing changes in what is sent, to whom or why: the same push token goes to the same recipient for the same purpose, on the same explicit consent under GDPR Article 49(1)(a), withdrawn the same way. The wording the member agrees to is version v2 from 2026-10-08; a consent given to the earlier wording stays valid, because it covered the same transfer with a fuller text, so nobody is asked again. The version does not move because 2026-10-08 is also the day this amendment is published, so no text carries a date earlier than its publication, the course taken for the amendments of 2026-09-14 made on the day their versions were published. Keeping it departs from section 3.3 of docs/legal/CHANGE-PROCESS.md, which keeps a version date only for an amendment that is unpublished or favourable: neither applies, because the earlier 2026-10-08 wording had been published and this amendment is not a change in the reader's favour. The departure is the controller's ruling of 2026-10-08. Apple Wallet is still limited to the operator's own test account, so no member could add a pass under the earlier wording, and the amendment takes away no right and adds no data, recipient or purpose. It takes effect on publication with no notice, on the owner's reasoning of 2026-10-08 (decision D13). The owner's request, the two rulings it needed (why the consent cannot sit in the sign-up terms or the privacy policy, and why a clearly worded button is explicit consent) and both wordings in all four languages are recorded in docs/legal/evidence/2026-10-07-apple-wallet.md (decision D14).

licences was amended again on 2026-10-08, the same day, with no version move, because the Add to Google Wallet button on the pass page and in the emails is now Google's own translated two-line button. Section 6 names the Slovenian, Macedonian, German and English versions under /google-wallet-button/, taken unchanged from the asset pack Google publishes with its brand guidelines, and says the home page still uses the single-line button. Nothing changes in what is sent, to whom or why. The reasoning for keeping the version is the one of the paragraph above.

licences was amended a third time on 2026-10-08, the same day, with no version move, because a member whose pass is saved in Google Wallet now sees Google's own translated "View in Google Wallet" button on the pass page. Section 6 names the Slovenian, Macedonian, German and English versions under /google-wallet-view/, taken unchanged from the asset pack Google publishes with its brand guidelines. The button links the member, by their own tap, to the pass Google already holds; nothing changes in what is sent, to whom or why. The reasoning for keeping the version is the one of the paragraph above.

privacy, dpa, terms-business and cookies move to 2026-10-12 and take effect on publication, because a business website can now take delivery orders as well as pickup orders. Where a site offers delivery, the customer gives a delivery address, confirms the point on a map where the order should arrive and may leave a note for the driver; the site shows the delivery fee, and the order value from which delivery is free, before the order and adds the fee to the total; and it refuses delivery, never pickup, for an address outside the area the business set. The address search runs on our own server against a copy of OpenStreetMap's address data, and the map images come through our own server from OpenStreetMap, so what a customer types or shares at checkout goes to no address or map service. The order status link shows the postcode and town of a delivery, never the street. The business delivers with its own staff and takes payment at the door. Its driver may open the delivery point in a navigation app of the business's choice; the business's order screens offer a link and a QR code that open it in Google Maps, and when they are used Google receives that point. Whichever app is used, that is a copy the business takes outside the platform (dpa section 4.3). The delivery address, its map point, its distance and the note for the driver are removed with the other order details at the end of the order retention period, a delivery fee stays with the totals, and nothing about a delivery is remembered in the browser. No site offered delivery before these versions were published: the code shipped switched off, and a site offers delivery only once we switch it on for that site. The change is not material for wallet account holders, because nothing changes for anyone who does not order a delivery from a business website, so no email goes to them. The owner decided on 2026-10-09 that these versions take effect at once, without the notice period section 14 of terms-business and section 14 of dpa describe, without the notice to businesses that section 17 of privacy describes, and without a direct notice, on the owner's classification: Globallis does not use Sites, and no real business uses ordering on the websites we host (his statement of 2026-10-12, before these versions were published). Nobody is asked to accept again. The decision, its reasoning and the evidence are recorded in docs/legal/evidence/2026-10-09-sites-delivery.md, and the decision is S26 in lawyer-review-checklist.md.

terms and delete-account move to 2026-10-12 and take effect on publication, and privacy and cookies were amended on 2026-10-12, the day their 2026-10-12 versions were published, with no version move, because a customer of a shop that takes points as credit can now add a points card for that shop to Google Wallet or Apple Wallet. privacy section 4.4 gains Points cards: which shops offer them (those that take points as credit, are not suspended and have not asked us to switch wallet passes off), what each card shows and what Google receives, the consent to the section 11 transfer that the shop's page asks for once for each card, what we keep for an Apple Wallet card, what a card does when the shop switches wallet passes off (an Apple Wallet card keeps updating, a Google Wallet card keeps the points it last showed), that a notification appears when the customer is given points as a gift or points are added in a correction, that the shop does not see whether a card was added, and that the card is expired at Google and voided in Apple Wallet when the customer's account or the shop's account is deleted or the shop stops using points; sections 10, 11 and 12 name points cards next to passes. terms section 11 gains a paragraph on points cards, including that notifications are turned off in the card's details in Apple Wallet and in Google Wallet's notification settings, and section 20 says that deleting your account expires and voids them too. terms section 6 also corrects the unit of shop credit: one point is the smallest unit of the shop's currency, a cent in euros and a denar in denars, which is what the platform has counted since points in euros became cents; it said one unit of the currency. delete-account sections 2, 5, 6, 7 and 15 and cookies section 4 name points cards next to passes, and cookies says that on a points card the Google Wallet button is a form that sends our server the tap with the page's own security token. cookies section 4 also corrects the membership pass's Google Wallet button: it is a link to our server, which then sends you to Google's page; the 2026-10-08 version, and the 2026-10-12 version as first published, called it a link to Google's own page, which was already untrue then. Takes effect on publication with no email to account holders: the terms correction changes nothing in a denar shop and no euro points shop exists; the additions describe an optional card that processes nothing until a customer adds it (evidence note 2026-10-11-points-wallet-cards.md, decision 1). The privacy and cookies versions do not move: their 2026-10-12 versions, which describe delivery orders (the paragraph above), were published earlier the same day, and this amendment is published that day too, so no text carries a date earlier than its publication, the course taken for the privacy amendment of 2026-10-08 (decision D14 in docs/legal/evidence/2026-10-07-apple-wallet.md). Keeping the date departs from section 3.3 of docs/legal/CHANGE-PROCESS.md, which keeps a version date only for an amendment that is unpublished or favourable: neither applies, because the 2026-10-12 versions had been published and this amendment is not a change in the reader's favour. The departure is the controller's ruling of 2026-10-12 (evidence note 2026-10-11-points-wallet-cards.md, ruling 16). Every delivery sentence of those versions stays as published. Nobody is asked to accept again. The cards open to every customer of a credit shop with the same release, never before this text.

licences moves to 2026-10-12 and takes effect on publication, because section 6 now says correctly where Google's button and Apple's badge appear. Google's two-line Add to Google Wallet button also appears on the pages of a shop that takes points as credit, the shop's card page and its rewards page, for a signed-in customer who may add a points card there, and the View in Google Wallet button appears there once the card is saved; Apple's badge appears there too, as a link to the card or to its consent screen. Since 11 October 2026 the home page shows Google's two-line button beside Apple's badge, both as still images with no link; the 2026-10-08 version said the home page used the older single-line button and that the badge appeared only where a member could add a pass, which stopped being true that day. The single-line button files are no longer shown on any page or in any email. No email: a factual correction of where the providers' artwork appears, which changes nothing about personal data, rights or obligations. Nobody is asked to accept again.

subprocessors moves to 2026-10-12, and dpa and terms-business were amended on 2026-10-12, the day their 2026-10-12 versions were published, with no version move; all three take effect on publication, because where they described Google Wallet and Apple Wallet for members only, they now name a shop's customers and their points cards too. dpa section 4.3 names Google Wallet pass and points card objects, and our Apple Wallet pass and points card records, among what we alone control. dpa section 7.3 says that where a shop takes points as credit and wallet passes are on for it, we create a points card's object at Google only when a customer asks to save the card, with the customer's name, their points at the shop and a QR code carrying their card's code, and the shop's name, programme name, logo and colours; that it is ours alone under section 4.3; and that it is expired when the customer's account or the shop's account is deleted or the shop stops using points, with the points set to zero and the name, the text and the barcode value blanked at Google. dpa section 7.4 says that Apple's push service tells a member's or customer's iPhone or Apple Watch that the pass or points card they added changed, only with that person's explicit consent, that a points card goes from us straight to the device and never through Apple, and that switching wallet passes off stops new points cards as it stops new passes; section 5 says our erasure procedure expires and voids points cards as well as passes; section 11 point 2 says that when the service ends we expire any Google Wallet pass or points card issued for the programme and void its Apple Wallet passes and points cards. terms-business section 8.4 point 3 names points cards among what Google receives and Apple's push service for customers who add a points card; section 8.5 says when a points card object is created at Google and that an Apple Wallet points card goes from us straight to the device; section 13.3 point 4 says that when the agreement ends your customers' points cards are expired at Google and voided in Apple Wallet. On the subprocessors page, which the DPA renders from the same rows, the Google LLC row names points cards next to passes, and the Apple Inc. row names a customer and a points card next to a member and a pass. No provider is added or removed. Google LLC, an existing sub-processor, taking on points cards is treated as a new purpose under dpa section 7.2, the conservative reading: the direct notice to the business owed it is that section's notice, and the objection window of that section runs from it. Apple Inc. is an existing recipient and not a sub-processor, so nothing new is announced for it. Nothing changes about a business's own account or data, and nothing about an organisation's members: their passes, the roster, holds and removals read as before. A change to the DPA or the business terms that touches data protection is material (the standing decision of 7 October 2026), so section 14 of each sets a notice period before it applies. The owner decided on 2026-10-12 that these versions take effect at once, without that notice period, as on 2026-10-08, and that the business owed notice is told directly by the owner on 2026-10-12 and asked to agree, without an email. This departs from section 14 of dpa and of terms-business and from section 3.3 of docs/legal/CHANGE-PROCESS.md. A business that does not accept the change may object under dpa section 7.2 or end the agreement under terms-business section 13.1 point 2. The dpa and terms-business versions do not move: their 2026-10-12 versions, which describe delivery orders (the delivery paragraph above), were published earlier the same day, and this amendment is published that day too, so no text carries a date earlier than its publication, the course taken for the privacy amendment of 2026-10-08 (decision D14 in docs/legal/evidence/2026-10-07-apple-wallet.md). Keeping the date departs from section 3.3 of the change process, whose grounds (an unpublished or a favourable amendment) do not apply, by the controller's ruling of 2026-10-12. Every delivery sentence of those versions stays as published. The decision, its reasoning and the evidence are recorded in docs/legal/evidence/2026-10-11-points-wallet-cards.md (decision 7, and rulings 13 and 16). Nobody is asked to accept again.

privacy, terms-business and dpa were amended again on 2026-10-12, the same day, with no version move, because the QR code for the route to a delivery is removed from the order tablet of a business website. Each said that the business's order screens offer a link and its tablet a QR code for the driver's phone, both opening directions in Google Maps; each now names the link alone (privacy section 5, Who sees your order; terms-business Annex B.5 point 12; dpa section 7.4). The link stays on the tablet and in the merchant portal, so the sentence is true both before and after the Sites release that removes the code. Nothing changes in what is sent, to whom or why, and no right or obligation changes. The version does not move because the amendment is published on 2026-10-12, the day its version was published, the course taken for the same-day amendments of 2026-10-08. Keeping the date departs from section 3.3 of docs/legal/CHANGE-PROCESS.md, whose grounds (an unpublished or a favourable amendment) do not apply, by the controller's ruling of 2026-10-12. It takes effect on publication with no email, like the delivery text it amends (docs/legal/evidence/2026-10-09-sites-delivery.md). Nobody is asked to accept again.

privacy moves to 2026-10-13 and takes effect on publication, because the checkout of a business website now shows the address under the pin while the customer moves the map. Section 5, Finding your address, says that each time the map stops, the customer's browser sends the point under the pin to our server, only to show the address there, and that we neither keep nor log these points. The address search and the shared position were already described and are unchanged. Nothing new is kept, no one new receives anything and the purpose is the same, so this is not a material change and no email is owed.

cookies moves to 2026-10-13 and privacy was amended on 2026-10-13, the day its 2026-10-13 version was published, with no version move; both take effect on publication, because the box Remember my details on this device, at the checkout of a business website that delivers, can now also keep the delivery address. From a delivery order placed with the box ticked, the customer's own browser keeps the delivery address, the point confirmed on the map and the note for the driver, together with the name, phone number and email address it already kept, so that the next delivery there starts with that address. Details saved earlier without an address get one only if the customer ticks the box on a delivery order. Nothing is kept on our server for this choice: the address reaches us only as part of an order the customer places, as every delivery address does. privacy section 5, Remembering your details, and cookies section 9, Remembered checkout details, said the delivery address is never saved; they now say what the box keeps and still say that order notes and the pickup or delivery time are never saved, and cookies section 2 (the two exceptions you control) lists the delivery address among the remembered details. The box starts unticked and the tick is the consent. The version of privacy does not move because the amendment is published on 2026-10-13, the day its version was published, the course taken for the same-day amendments of 2026-10-12. It takes effect on publication and no email is owed, under the standing rule of section 3.3 of docs/legal/CHANGE-PROCESS.md: no real account holder, customer or business is affected, and nobody has yet ordered from a business website as a real customer. Nobody is asked to accept again. The decision is recorded in docs/legal/evidence/2026-10-13-sites-remember-delivery-address.md.

privacy and cookies move to 2026-10-14 and take effect on publication, because the remembered checkout details now say exactly which map point they keep. privacy section 5, Remembering your details, and cookies section 9, Remembered checkout details, said that a delivery order placed with the box ticked keeps the point the customer confirmed on the map. A customer who chooses an address from the list without setting an entrance never confirms a point on a map: what is kept then is the building's point. Both now say the address's point on the map, the building or the entrance if the customer set one. This clarifies what has been kept since 2026-10-13 and is not a new practice: the same data, kept the same way, in the customer's own browser only. Not a material change, so it takes effect on publication: no email is owed, and nobody accepts again.

terms, privacy, terms-business and dpa move to 2026-10-15 and take effect on publication, because points can now expire after a time without a visit. Every points shop chooses how long its points last without a visit: 12 months unless it sets 3 to 36 months, or never. Each visit that earns or spends points there starts the count again, and so do points added to the card, such as a gift, a refund or a correction; a change of period counts from the day of the change, and no count starts before 2026-10-15. Customers see a countdown in the last 30 days and get one email when the countdown starts unless they unsubscribed from engagement email. The rule affects what a person earns, so it is material in kind, and a 30 day notice email would be owed. The texts take effect on publication with no email, because the owner confirmed on 14 October 2026 that no real customer holds points that the rule could affect, and in any case the first possible expiry is one full period after the effective date (12 months on the default, 3 at the shortest). Both points shops are held by the owner's own account, and the one run for a client asked for this rule itself. The one other real business that accepted terms-business and dpa, which runs no points and none of whose data the change touches, is told directly by the owner under their section 14, as on 12 October 2026. Nobody accepts again. The counts and the decision are recorded in docs/legal/evidence/2026-10-14-points-expiry-notice.md.

privacy, cookies and terms move to 2026-10-18 and take effect on publication, because a points shop's till gives a slip printed on paper, shows it as a QR code on its screen or, at some counters, passes it to the customer's phone by a tap, and the texts said printed. The tap has been live since 12 October 2026 and Show QR, which shows the slip's code in a large window on the till's screen, since 13 October 2026; a till with no printer has shown its slip on its screen since 29 August 2026. privacy section 4.2 described only a printed slip that the cashier hands over, which was untrue for a customer of a counter that shows the code or takes a tap; it now names all three ways, says that the device reads nothing that identifies a phone held to it, and says that the slip record notes how the slip was handed over. privacy section 4.12 also lists, among the exports a shop's owner or admin can take, a points shop's sale slips with the name of the customer who claimed each, which the dashboard has offered since 6 September 2026 and the list left out. cookies section 4, till_device, says the till hands out slips printed, shown on its screen or passed to a phone by a tap, where it said it prints them, and that a business retires a till from its dashboard while we revoke one the business reports lost, where it said a business could also revoke it from its dashboard, which no business has been able to do since 8 September 2026; its token lasts 365 days or until the till is retired or revoked, where it said until revoked. It is set when a business pairs a till through a pairing link or its QR code from its dashboard, signed in with Google, where it said with a one-time pairing code, and section 11 says that a till whose cookie is deleted must be paired again through a pairing link from the business dashboard, where it said with a fresh code: since 5 September 2026 the dashboard has shown a pairing link and its QR code, not a code, and pairing has needed a Google sign-in. Section 4's opening paragraph now says that a stamp till's token stops working once it is revoked and a paired till's once the till is retired or revoked, where it said the business can revoke either at any time from its dashboard, and the cashier_device row and section 11 say that a business in stamps mode can revoke a stamp till from its dashboard, where they said the business could: only a business in stamps mode has that list on its dashboard. terms sections 6 and 8 say that claiming a slip puts the points on the card and that a slip pays the points it carries, where they said scanning it and the points printed on it. The same data, kept the same way, for the same purpose and the same recipients: a clarification of privacy and cookies, and a minor change of terms under its section 21, which changes no right, obligation or value. No email to account holders, and nobody accepts again. Privacy section 17 owed businesses 15 days' notice of this change; by the owner's decision of 16 October 2026 it takes effect on publication without that notice and without a direct notice, and businesses are told in the business notice email. Evidence: docs/legal/evidence/2026-10-18-printing-and-paperless.md.

terms-business and dpa move to 2026-11-19. They were published on 2026-10-19, the day the notice email went to every business owed it, and take effect on 2026-11-19, once 30 whole days have passed after the day the email was received (section 14 of each, and section 15 point 2 of terms-business); until then the versions they replace apply. A points business's tills give a sale slip printed, shown on the till's screen or, at a till that offers it, passed to the customer's phone by a tap, and the business documents said printed. terms-business Annex A.3 point 1 and A.4 name all three and say a slip is claimed by a scan of its code or by a tap. A.4.4 says a retired till's slips stay valid for their seven days and that we revoke a till a business reports lost, which is when its unclaimed slips stop being honoured; it said a retired till's unclaimed slips stop being honoured, which the platform has never done, and that a business revokes a till itself, which no business has been able to do since 8 September 2026. It also says a till is paired through a pairing link or its QR code from the dashboard, signed in with Google, where it said with a one-time pairing code, which the dashboard has not shown since 5 September 2026. A.13 point 2 says a retired or revoked till no longer hands out slips. Section 5 point 6 and A.13 point 1 say that changing the cashier password stops every trusted cashier device and that a stamps business can also revoke one from the device list of its dashboard, where they said any business could revoke one in the dashboard: only a stamps business has that list. A.13 point 1 also says that the security page shows recent events and that, at a stamps business, the device list shows when each device was last active. A.9 lists, as a fourth export, the sale slips a points business can download with the name of the customer who claimed each, which the dashboard has offered since 6 September 2026 and the list of three left out. dpa section 4.1 names the sale slips your tills issue, however they are handed over, and how each was handed over, and says that the flag raised when another shop's reward is scanned at your counter shows on the security page of your dashboard without the customer or that shop, where it said you see every anti-fraud flag in the customer's activity: one shop never sees another shop's customers (section 8.4). dpa section 8.2 says of trusted cashier devices what section 5 point 6 of the business terms says. A change to the business terms or the DPA that touches data protection or a feature a business uses is material (the standing decision of 7 October 2026), so every business owed notice was emailed 30 days ahead. Nobody accepts again. Evidence: docs/legal/evidence/2026-10-19-printing-and-paperless-business-notice.md.

privacy and cookies move to 2026-10-21 and take effect on publication, because two translations of the privacy notice named the till slips a shop holds with words for a till receipt, and the cookies page's section 3 said that the cashier and till device cookies mark tablets, and its till_device row called every paired till a tablet, while a stamp till or a paired till can also be a phone or a computer. privacy section 4.14, What a shop sees, says that a shop sees the groups whose points, stamps or till slips it holds. The Macedonian version said "сметки од касата" (till bills) and the German "Kassenbelege" (till receipts); each now uses the word its own version uses for the slip everywhere else, "ливчиња од касата" and "Bons". The English ("till slips") and the Slovenian ("blagajniške listke") already said so and do not change. cookies section 3 said that the cashier and till device cookies mark tablets the business itself registered at its counter, and section 4, the till_device row, said that a business pairs a counter till tablet, that the cookie marks that tablet as a paired till, and that retiring or revoking the till stops the tablet on its next request. A business in stamps mode can register a stamp till on any tablet, phone or computer at its counter, as the Cashier Screen card of its Cashier Devices page says, and a business pairs a till on the tablet, phone or computer it wants to use, as the Pair a loyalty device tile of its dashboard says. So in all four languages section 3 now says devices, with the word its version already uses for a device, and the row says a counter device and that device, each with the word its version already uses for the counter device; the cashier_device row and its line in section 11 are unchanged. The same data, kept the same way, for the same purpose and the same recipients. No notice is owed. Privacy section 17's notice to businesses is not engaged: for businesses the English version prevails (section 17, its languages paragraph), and the English text does not change. For consumers, whose own language version prevails, it is a minor correction that changes no data, purpose, recipient or right, so it takes effect on publication with no email, which section 17 promises only for a material change. Cookies section 12 promises an email only before storage that needs consent, and this changes the wording of one sentence and one row and adds or changes no cookie. stampomat-sites needs no change: checked on 2026-10-20 at its origin/main 8108cd45, its config/legal.php keeps its own privacy (2026-10-14, the Sites notice) and no cookies, and mirrors only terms-business and dpa. Nobody accepts again.

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.

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.