Allowing Under-18 Customers — Parental Consent Patterns

What Is This?

This article is for vendors deciding whether to let customers under 18 join their loyalty program. Pixalink has a built-in age restriction that blocks under-18 sign-ups by default, and there are a few operational patterns vendors use when they need to accept minors. There is also one part of this story that is not yet built — a native parental-consent flow — and this article is honest about that.

If you're a tuition center, family-friendly cafe, or any business near a school, read this before you decide.

The Existing 18+ Toggle

Pixalink ships with a setting called Enable age restriction upon registration. Its helper text reads: If enabled, new customers must be at least 18 years old.

• It lives on the loyalty portal feature controls and is on by default.
• When it's on, customers must be at least 18 years old to sign up. The date-of-birth picker on the registration page will not let them choose a date that makes them under 18.
• The toggle sits inside the Pixalink internal panel and is managed by the Pixalink team. If you want it changed for your account, message support and we'll adjust it for you.
• An information button next to the toggle opens a modal titled Why Age Restriction Matters, which explains the legal context for Pixalink admins.

The toggle exists because of Malaysian law. Under the Personal Data Protection Act (PDPA) 2010, processing personal data requires valid consent — and a minor (anyone under 18) cannot legally consent to their own data being processed, so a parent or guardian must consent on their behalf. The PDPA Amendment 2024, administered by the Department of Personal Data Protection (JPDP), explicitly raised penalties to RM 1,000,000 and up to 3 years imprisonment, and breaches involving minors face harsher scrutiny. The Malaysian Code of Advertising Practice (MCAP) also restricts marketing aimed at children, including promotional messages that exploit a child's inexperience.

We strongly recommend keeping this toggle enabled.

Privacy Policy Approach

If you want a simple, defensible posture, this is the most common pattern:

• Keep the 18+ toggle on.
• Add a clause to your privacy policy stating that the loyalty program is intended for users 18 and above, and that anyone signing up confirms they meet that age.

Tuition Center Precedent

We have one tuition center customer that needs to register minors as part of their core business. They handle parental consent through a manual operational process — not a system feature:

• A staff member sits with the parent at the time of registration.
• The staff member confirms verbally that the parent consents to the child's data being processed.
• Only then does the child get registered into the loyalty portal.

This works for them because registration always happens in person, with a staff member present. It does not scale to self-serve sign-up over a QR code or WhatsApp link.

Real-Life Example

Farah runs Ceria Learning Hub, a tuition center in Petaling Jaya for students aged 10 to 17. She wants every enrolled student to earn loyalty points for showing up to class, but most of her students are under 18.

She decides on a hybrid approach:

• Pixalink keeps the 18+ toggle off for her account, because her entire business is built on minors.
• During the on-boarding interview with each new family, her front-desk staff walks the parent through a paper consent form covering data processing, marketing, and reward redemption.
• Only after the parent signs that form does the staff member register the student in the loyalty portal using the parent's phone number as the contact channel.
• Her privacy policy is updated to spell out that all loyalty data for under-18 students is processed under documented parental consent obtained at enrollment.

It's slower than self-serve sign-up, but it's defensible — and it matches what our other tuition center customer already does.

Open Question — Native Parental Consent Flow (NOT YET AVAILABLE)

Vendor enquiries have raised whether the app could add a built-in parental-consent flow — for example, a pop-up that collects the parent's phone number during registration, or a consent button the parent has to press before a child can be registered.

This feature does not currently exist. There is no parent-phone-number field, no consent button, no parent-side approval link, and no audit trail tying a child registration to a parent's confirmation. None of it is built.

There is also a hard problem behind this question that we have not yet solved: there's no reliable way to verify that the phone number entered actually belongs to the customer's parent. A parent could legitimately approve. A child could also enter a friend's number, or any number they have access to, and click the consent button themselves. Without a separate identity check, a "consent button" doesn't actually prove a parent consented — and that's the whole point.

If a native parental-consent flow is critical to your launch, contact engineering before you commit. We'll let you know if anything has changed since this article was written.

Good to Know

• The 18+ toggle is on by default. If you want it off, ask support.
• Date of birth is collected at registration; the system uses it to enforce the 18+ rule.
• Until a native consent flow exists, your two options for under-18 customers are: (1) keep the 18+ block and rely on a privacy-policy clause, or (2) handle consent manually at the point of registration, like the tuition center example above.
• If you market to your customer list, remember the MCAP rules — even with parental consent, marketing aimed at minors carries extra risk.

Need Help?

Reach out to our support team — we're happy to walk through the right setup for your business.