Design the policy. Test the failure paths. Then decide.
NP AgeVerify 1.2.11 combines country and catalogue age rules with four declaration methods, per-language copy and a branded storefront. This lab lets you inspect the effective decision, real UI, stored evidence and operational limits without submitting personal data.
- 1.2.11
- deterministic ZIP · SHA-256 published
- 4
- declaration methods
- 6 × 5
- themes × layouts
- PS 8 + 9
- live runtime verified
An age gate is a policy system—not only a popup.
Choose the evidence model
DOB, birth year, checkbox and Yes/No are declarations. None establishes identity or who entered the value.
Define age precedence
A detected-country rule replaces the base policy; category, product and cart tiers can raise it. The highest applicable age wins.
Design the interruption
Select one of six themes and five layouts, then control logo, icon, palette, background, consent text and exclusions.
Own the operations
Monitor audit and analytics, export CSV, test GDPR hooks and operate audit retention. Seven-day guard cleanup is not audit-log retention.
Inspect the exact age-gate release before trusting it with a live policy.
Match the delivered ZIP, inspect the byte-identical PS8/PS9 source, locale catalogs and real EN/FR/ES/IT captures, then decide whether self-declaration fits the risk and operating model of your store.
One public version, one private artifact identity.
The catalog current-version pointer and private download path resolve to the same deterministic ZIP exercised by every lifecycle and browser gate.
993ab5b044446d751ad29698251effa43ecba6b8a18655973b1cae5bcee0b4f8The package has no PrestaShop Product Key and no authenticated official Validator run is claimed. Marketplace submission remains gated even though direct delivery is live.
Reproduce the gate without submitting personal data.
Use an invented date. Change the base policy, detected-country override and catalogue tiers to see the effective age, cookie, checkout and audit decision.
- Calculated example age
- 24
- Effective required age
- 21+
- Gate on this surface
- Visible
- Decision cookie
- Would be set for 30 days
- Checkout
- No checkout redirect in this state
Browser record
Signed first-party HttpOnly np_age_verified token; SameSite=Lax; Secure on HTTPS; session fallback when persistent cookies are unavailable.
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.2.11 has no automatic audit-log expiry or purge. Cookie days do not delete audit rows; seven-day cleanup applies only to rate-limit and alert guard 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 shopper decision into merchant operations.
1. Show the effective rule in the storefront
The real PS9 gate displays the required age and keeps confirm/leave actions reachable. Full DOB is one of four methods; this scene uses the luxury theme.
Open this scene in the full tour →
2. Configure policy, scope and presentation
The responsive back office starts with configuration health, then groups verification, targeting, design, security and alert controls into five task sections.
Open this scene in the full tour →
3. Investigate and export decisions
Filter by date, event and result, inspect the effective age and context, then export the selected period as CSV. The table stores birth year when supplied—not full DOB.
Open this scene in the full tour →
4. Monitor the operating pattern
Aggregate analytics surface passed, failed, blocked and storage-fallback events so the merchant can spot friction and abuse without an external analytics SaaS.
Open this scene in the full tour →
First-party processing still needs a retention decision.
| Location | What 1.2.11 uses | Operational boundary |
|---|---|---|
| Verification request | DOB fields, birth year, acknowledgement or Yes/No according to the selected method; a signed pending age binds the request to the rendered rule. | Same-origin processing. Full DOB is evaluated but not stored in the audit table. Use a specialist verifier when stronger evidence is required. |
| Browser decision | Signed first-party HttpOnly np_age_verified cookie, SameSite=Lax, Secure on HTTPS; a short signed pending-age cookie and storage probe support the flow. | Cookie duration does not delete server audit rows. When persistent cookies fail, a secure session fallback is used for that visit. |
| Audit table | id_shop · id_customer · id_cart · event_type · result · rule_context · minimum_age · birth_year · ip_hash · user_agent_hash · date_add | Filtered view, CSV and GDPR customer export/delete hooks exist. The audit log has no automatic age-based purge; the merchant must operate retention. |
| Rate-limit and alert guards | Hashed-IP attempt counters, cooldown timestamps and alert-window counters used to throttle DOB/year abuse and optionally notify operators. | Guard rows older than seven days are pruned opportunistically. This cleanup does not apply to the audit table. |
Match the confidence level to the real risk.
The European Data Protection Board distinguishes self-declaration from stronger age-assurance methods, recommends a risk-based and proportionate choice, and notes that self-declaration depends mainly on user goodwill. It also calls for purpose limitation, minimisation, transparent retention and appropriate security. NP AgeVerify implements a merchant-controlled self-declaration gate; this page is not legal advice.
Read EDPB Statement 1/2025 ↗Necessity first
Document why this exact product, route and audience need an age decision before processing a declaration.
Proportionate confidence
Self-declaration is low-confidence evidence. Match the method to the consequence of a wrong decision.
Minimise and limit purpose
Assess whether birth year, linked IDs and stable hashes are necessary; never reuse the audit trail for unrelated profiling.
Operate deletion
Assign an owner, period, deletion job, verification evidence, backup policy and incident response for audit rows.
Use self-declaration only where self-declaration is enough.
Good fit · reviewed self-declaration
Independent review accepts declaration evidence, you want first-party processing, and country/catalogue rules plus brand control matter.
Conditional fit · customised stack
Custom checkout, controllers, overrides, consent and CDN/cache layers require production-like staging across every restricted route.
Not a fit · verified identity or delivery
Use a specialist process for documents, biometrics, trusted age tokens, payment identity, carrier checks or proof at delivery.
Prove the exact store, route and edge case before launch.
| Decision or risk | What 1.2.11 does | What the merchant must prove |
|---|---|---|
| DOB boundary and direct requests | The server rejects impossible dates, years before 1900, future dates and non-strict integer fields. A future DOB logs failed and never sets the cookie. | Test before/on/after birthday, leap day, impossible date, future date, arrays, decimals, negatives, zero and partially numeric fields. |
| Country and tier precedence | Detected country replaces the base age; applicable category, product and cart tiers can raise it. The maximum is signed into the pending attempt. | Test missing/unknown country, each mapped country, products in multiple categories, product overrides and a mixed-age cart. |
| GeoIP source accuracy | The module can use trusted CDN country headers or an available GeoLite2 database. If no country resolves, the base policy applies. | Validate proxy/header trust, IPv4/IPv6, VPN/unknown behavior, database availability and the fallback policy in production topology. |
| Checkout and custom controllers | A restricted cart without a matching decision is blocked before checkout. URL/controller exclusions intentionally bypass selected surfaces. | Test classic and one-page checkout, express payment, cart restore, account/auth routes, custom controllers and every excluded URL. |
| Cookie and session fallback | A signed HttpOnly SameSite=Lax cookie records the verified threshold. When persistent cookies fail, the visit can use a secure session fallback. | Test HTTPS, subdirectory installs, blocked cookies, private browsing, expiry, changed threshold, multiple tabs and cache/CDN behavior. |
| Audit retention | Audit rows do not expire automatically. Seven-day opportunistic cleanup covers rate-limit and alert guard tables only. | Prove the merchant deletion job, permissions, backup handling, failure alert, GDPR hooks and row counts after the chosen period. |
| Crawler and accessible UX | Recognised search/social preview bots can bypass the gate. Blocking layouts trap focus; inline mode is a region. No indexing or accessibility outcome is guaranteed. | Use keyboard and screen reader; inspect mobile scroll, rendered HTML, internal links, previews, robots and Search Console on the exact theme. |
Know the boundary before production
Is this identity verification?+
No. The visitor declares DOB, birth year or a confirmation. The module does not inspect documents, biometrics, payment identity, government data or delivery evidence and cannot prove who made the declaration.
Does 1.2.11 support country-specific and product ages?+
Yes. A detected ISO2 country can replace the base age; category, product and cart tiers can raise it. The effective requirement is the highest applicable value. GeoIP availability and accuracy must be tested in the real network path.
Are future dates rejected by the server?+
Yes. Version 1.2.11 rejects future and impossible DOBs, years before 1900 and malformed integer inputs. Direct-request regression tests passed on both PS8 and PS9 demo runtimes.
Does it store the full date of birth?+
The full DOB is sent to the same-origin endpoint for the decision, but the audit table has no day or month columns. It can store birth_year with linked IDs, outcome, context, effective age, hashed IP/user agent and timestamp.
Can I configure automatic audit retention?+
No. Audit rows have filters, CSV and customer export/delete hooks, but no age-based scheduler. The merchant must operate retention. The seven-day cleanup in 1.2.11 applies only to rate-limit and alert guard rows.
Will it work with every checkout and theme?+
No universal guarantee is possible. Version 1.2.11 is runtime-verified on PrestaShop 8 and 9, but custom controllers, one-page checkout, express payment, overrides, consent and cache/CDN layers require production-like staging.
Does buying it establish legal compliance?+
No. Applicable ages, evidence strength, legal basis, notice, retention, accessibility, delivery controls and market rules depend on the merchant context. Obtain independent legal and privacy review.
Keep the simulator, real screens and release evidence together.
The product experience publishes the exact 1.2.11 SHA-256, locale-matched runtime captures, installation checklist and €49 one-time price. Buy only after the evidence model, routes, accessibility, data notice and merchant-run retention pass independent review and staging.