PrestaShop age-verification decision guide: evidence, data and staging (2026)

An age gate is a technical control, not a legal conclusion. The required rule can change with the product, destination, sales channel, evidence standard and delivery process. Before choosing a PrestaShop module, obtain an independent legal and privacy review for the exact operation. This guide helps turn that review into product and staging questions; it is not legal advice.

1. Name the evidence requirement before the feature

“Age verification” is often used as a catch-all, but the European Data Protection Board distinguishes three broad models:

• Self-declaration: the visitor states or types an age-related attribute. The service does not independently prove who entered it.
• Age estimation: a system estimates age from signals. Accuracy, bias, redress and data sensitivity become central questions.
• Age verification: a stronger source or credential is checked. That can increase confidence and also introduce more parties, data and failure modes.

These are not interchangeable feature tiers. Decide the confidence and evidence the store actually needs, then reject products that implement a different model.

2. Apply the official privacy principles to the exact flow

The EDPB says age assurance should be risk-based and proportionate, limited to a specified purpose, and designed to minimise data. It also calls for transparency about what is processed and how long it is kept, appropriate security, and evidence that the chosen method is effective. The statement notes that self-declaration reliability depends mainly on user goodwill. Read the EDPB Statement 1/2025 on age assurance before assessing a product.

Turn those principles into six concrete questions:

1. Why is an age decision necessary on this exact route?
2. What confidence level must the decision provide?
3. What is the minimum attribute the store needs to learn?
4. Which parties receive the input or result?
5. Which records remain, for how long, and who deletes them?
6. How can a wrong or inaccessible decision be challenged?

3. Inspect implementation, not just the privacy headline

“First-party” and “no external verification call” are useful facts, but they do not prove that a module has no server-side record. Ask for the table schema, cookie attributes, deletion mechanism and a real admin screen from the release you will receive.

For example, NP AgeVerify 1.2.10 uses a signed first-party HttpOnly SameSite=Lax decision cookie and makes no external identity call. Its audit log still contains shop, customer and cart IDs when present; event and result; rule context; effective minimum age; birth year when the selected method supplies one; hashed IP and user agent; and a timestamp. The audit log has no automatic retention or purge control. Hashing alone does not make linked identifiers anonymous.

The current server path independently rejects impossible dates, dates after today, years before 1900 and malformed integer fields. Direct requests containing arrays, decimals, negatives, zero or partially numeric values are rejected before conversion. Treat that as a testable release boundary, not a reason to stop testing: run the same cases on the exact package and production-like stack you will deploy.

Use the PrestaShop age-verification buyer lab to simulate the exact 1.2.10 decision, country and catalogue precedence, cookie fallback and every stored field before considering a purchase.

4. Test geographic and catalogue precedence

NP AgeVerify 1.2.10 can replace its base age with an ISO2 country rule when a trusted CDN header or available GeoLite2 database resolves the visitor. Category, product and cart tiers can then raise the requirement. The effective decision is the highest applicable value and is signed into the pending verification attempt.

GeoIP is not the same as a shipping-destination rule and can be unknown or wrong. Test proxy trust, IPv4/IPv6, VPN and fallback behaviour; do not treat a detected country or screenshot number as a legal conclusion.

5. Build a retention operation before enabling the log

Cookie lifetime and server-log retention are different controls. Expiring a browser cookie does not remove a database row. When the module has no purge function, the merchant needs a separate, tested process with:

• a documented period and owner;
• a least-privilege deletion job or manual procedure;
• backup and restore handling;
• failure alerts and evidence that deletion actually ran;
• a response path for access, deletion and incident requests.

If the organisation cannot operate that process, choose an architecture with an appropriate built-in retention or no-log model instead.

6. Stage the failure paths

Test the release on a clone of the production stack:

• the day before, on and after the threshold birthday;
• invalid dates, leap day and browser validation differences;
• unrestricted and restricted products, categories and carts;
• classic and custom checkout controllers and express payment paths;
• cookie expiry, blocked cookies, HTTPS and a changed threshold;
• keyboard, screen-reader and mobile operation;
• rendered HTML, internal links, robots directives and Search Console;
• server-row growth and the complete deletion process.

NP AgeVerify 1.2.10 can bypass recognised search and social-preview crawlers and uses a focus trap for blocking layouts, while inline mode is exposed as a region. Neither accessibility nor indexing is guaranteed by installing the package; verify the exact theme, HTML and crawler path.

Bottom line

Buy an age-gate module only after the evidence model, data inventory, retention operation and exact-stack tests are clear. NP AgeVerify provides self-declaration only. Its controls may fit a reviewed simple policy, but installing it does not create compliance by itself.

Inspect the exact release, screenshots, SHA-256 and purchase terms on the NP AgeVerify product experience.