Test the gate—and inspect every stored field.
Release 1.0.0 is a date-of-birth self-declaration gate, not identity verification. Reproduce its decision, inspect its real UI and server log, then decide whether one global threshold and merchant-operated deletion fit the exact store.
- 1.0.0
- exact package verified by SHA-256
- PS ≥ 8.0
- minimum declared by the delivered code
- 1
- global threshold; no country rules
- 1–365
- configurable cookie days; log retention separate
Choose the evidence model before choosing the module.
Decide the required confidence
The release compares a typed date with one threshold. It cannot establish identity or who entered the date.
Choose one catalogue scope
Gate the whole store or manually list category and product IDs. There is no per-country, address or GeoIP branch.
Own the server log
Passed and failed checks log birth year plus hashed network/browser identifiers. Version 1.0.0 never purges rows automatically.
Stage checkout and SEO
Restricted checkout redirects to cart. The release has no crawler bypass, so custom controllers, keyboard flow and rendered HTML require exact-stack testing.
Reproduce the gate without submitting personal data.
Use an invented date. The simulator mirrors the package’s age, scope, cookie and checkout decisions and then shows which record would be written.
- Calculated example age
- 24
- Gate on this surface
- Visible
- Decision cookie
- Would be set for 30 days
- Checkout
- No checkout redirect in this state
Browser record
First-party HttpOnly np_age_verified token; Secure only on HTTPS; no explicit SameSite attribute in 1.0.0.
Server record
Event for this simulated state: verify / passed / birth_year 2002
Columns in the delivered log table
id_shop · id_customer · id_cart · event_type · result · rule_context · minimum_age · birth_year · ip_hash · user_agent_hash · date_add
Release 1.0.0 has no automatic log expiry or purge. Cookie days do not delete server rows.
Product simulator only. It does not determine the applicable age, evidence level, lawful basis, retention period or delivery control for any product or country.
Inputs stay in this browser and are never submitted to Neuroplugin. Use invented examples only.
Follow the shipped path from storefront to settings.
1. Block the configured storefront surface
The real overlay locks scrolling, traps focus and offers explicit confirm or leave actions. It does not close on a backdrop click.
Open this exact product scene →
2. Submit day, month and year
The same-origin endpoint checks the calendar date and age. Passing sets the first-party cookie; passed and failed results include the submitted birth year in the server log.
Open this exact product scene →
3. Configure only what 1.0.0 actually ships
This real HelperForm shows the exact controls: enabled state, storewide/selected scope, one age, cookie days, restricted IDs, title, message and exit URL.
Open this exact product scene →
“No external call” does not mean “no server record”.
| Location | Exact 1.0.0 data | Operational boundary |
|---|---|---|
| Browser cookie | np_age_verified: deterministic SHA-256 decision token derived from the store cookie key, module name and minimum age. | HttpOnly; Secure only on HTTPS; 1–365 days; no explicit SameSite attribute in 1.0.0. Changing the minimum age invalidates the old value. |
| Server event row | Shop, customer and cart IDs; event, result, context, minimum age, birth year, SHA-256 IP hash, SHA-256 user-agent hash and timestamp. | Birth year is written for passed and failed DOB checks. Hashing does not make identifiers anonymous by itself. |
| Retention operation | No retention setting, scheduled purge or row-level deletion UI in release 1.0.0. | The merchant must define and operate deletion separately. Uninstall drops the whole log table; that is not a normal retention workflow. |
Apply necessity, proportionality and minimisation before activation.
The European Data Protection Board distinguishes self-declaration from stronger age-assurance methods, says the selected method should be risk-based and proportionate, and notes that self-declaration reliability depends mainly on user goodwill. It also calls for strict purpose limitation, data minimisation, transparent retention and appropriate security. This page applies those principles to the delivered package; it is not legal advice.
Read EDPB Statement 1/2025 ↗Necessity first
Document why an age decision is needed for the exact product, route and audience before processing any DOB data.
Proportionate confidence
Match the method to the risk and required evidence. Self-declaration is the lowest-confidence model in this comparison.
Minimise and limit purpose
Assess whether birth year, linked IDs and stable hashes are necessary; do not reuse the event log for unrelated profiling.
Set a real deletion process
Version 1.0.0 cannot enforce a retention period. Assign an owner, schedule, verification evidence and incident response outside the module.
A simple gate is useful only when simple evidence is enough.
Potential fit · one reviewed self-declaration rule
Only after the future-date server defect is patched and retested: one global threshold is sufficient, independent review accepts typed DOB evidence, and the merchant can own transparency, logging and deletion.
Conditional fit · restricted IDs and custom checkout
Manual IDs, category membership and controller detection can drift. Proceed only when every product, cart and checkout route passes the production-theme clone.
Not a fit · country or verified-identity decisions
Use another process for per-country thresholds, shipping-address rules, documents, biometrics, trusted age tokens, delivery checks, no-log architecture or automatic retention.
Prove the failure paths before placing it in front of the catalogue.
| Decision or risk | What 1.0.0 does | What the merchant must test |
|---|---|---|
| Threshold boundary | The visible form limits the year; the server checks calendar validity and compares DateTime::diff()->y with one minimum age. | Test day before/on/after the birthday, leap day, malformed date and a future date in the current year. |
| Direct future-date request · 1.0.0 defect | Storefront JavaScript rejects future years, but the endpoint does not. Its absolute year component can make a sufficiently distant future date pass. | Block production reliance until the endpoint explicitly rejects birth dates after today and direct-request regression tests pass. |
| Restricted scope drifts | Product and category IDs are parsed from manual comma-separated lists. | Move products between categories, test combinations and confirm unrestricted catalogue routes remain usable. |
| Checkout controller mismatch | Blocking recognizes selected core controller names/classes and cart contents. | Test classic checkout, one-page checkout, payment express buttons, cart restore links and custom controllers. |
| Cookie and session edge cases | The token changes when minimum age changes; Secure is conditional on HTTPS. | Test HTTPS, subdirectory installs, expiry, age-setting changes, private browsing and blocked cookies. |
| Log grows indefinitely | Every relevant event inserts a row; no scheduled deletion runs. | Prove the external deletion job, permissions, backup handling, failure alerts and row counts after the chosen period. |
| Modal harms access or discovery | Focus trap and data-nosnippet exist; crawler bypass and indexation guarantees do not. | Use keyboard and screen reader; inspect rendered HTML, internal links, robots and Search Console on the exact theme. |
Before you put the gate in production
Is this identity verification?+
No. A visitor types a date of birth. NP AgeVerify 1.0.0 does not inspect identity documents, biometrics, trusted credentials or delivery evidence and cannot know who entered the date.
Does 1.0.0 have per-country thresholds or GeoIP?+
No. It has one global minimum age. Country, shipping address and GeoIP do not participate in the delivered decision.
Can I rely on the exact 1.0.0 endpoint in production?+
Not before a patch. The visible form rejects future years, but the server endpoint does not independently reject a birth date after today. Because it uses the absolute year component from DateTime::diff(), a direct future-date request can pass. Patch the server check and add direct-request regression tests first.
Does the module keep the full birth date?+
The delivered table does not have day or month columns, but passed and failed checks store birth_year together with linked IDs, hashes and timestamp. The full date is submitted to the same-origin endpoint for the decision.
Can I configure log retention?+
Not inside 1.0.0. There is no retention setting, scheduled purge or deletion screen. A separate merchant-owned process is required if the module is activated.
Will it work with every checkout and theme?+
That is not guaranteed. Version 1.0.0 declares PrestaShop 8.0.0 as its minimum, but custom controllers, overrides, one-page checkout, payment buttons, theme CSS and consent tools require exact-stack staging.
Does buying the module establish compliance?+
No. The applicable rule, evidence level, legal basis, notice, retention, accessibility and delivery controls depend on the merchant’s actual context. Obtain independent legal and privacy review.
Keep the simulator, package evidence and purchase terms together.
Open the product page for the exact SHA-256, three real scenes, installation steps and €49 one-time licence. Buy only after self-declaration, server logging and merchant-run retention have passed independent review and staging.