Building a Subscription Billing App in South Africa Without Giving a Child Payment Access

A subscription billing app aimed at South African families needs two distinct account types: one that holds the payment method and owns the subscription (the parent's), and one with no payment surface whatsoever (the child's), reached through a lightweight, credential-free sign-in so a minor is never asked to see, enter or confirm billing details. This separation is a POPIA requirement, not just good design.

How to structure subscription billing when your app's user is a child

The subscription and the app session belong to two different people, and the account architecture should say so explicitly rather than treating "the user" as a single row in a database. Most billing tutorials assume the payer and the user are the same adult, an assumption that collapses the moment your actual daily user is eight years old.

In practice this means splitting the account model into two roles with very different privileges:

1. The parent's account holds the subscription: the billing SDK integration, payment method, receipts, and cancellation controls.
2. The child's account has no payment fields anywhere in its interface, no recoverable email-and-password login, and no direct route to the billing SDK.
3. The relationship between them is checked server-side on every entitlement request, rather than stored as a shared secret on the child's device.

This is what a family subscription app architecture needs to get right: not the billing integration itself, which most SDKs handle well, but the deliberate choice to keep a child account without payment details in its data model. Get that separation wrong and the result is exactly the kind of in-app purchase children privacy problem that is far harder to retrofit than to design in from day one.

Why most billing guides get this wrong

Most subscription billing guidance is written for apps where the payer and the user are the same adult, and that assumption is exactly what breaks when the end user is a minor. The cost of getting it wrong is not hypothetical. In August 2026, TikTok's parent company ByteDance agreed to a $400 million settlement over child-privacy-law violations, $300 million paid immediately and a further $100 million tied to vacating a prior consent decree, one of the largest recoveries ever secured under the US's COPPA regime, according to The Hacker News. The underlying failure, a child's account exposed to a commercial surface it should never touch, is one South African apps can build into their own architecture just as easily if account roles aren't separated properly.

We ran into exactly this decision on a South African EdTech assessment platform for primary-school maths, built out through an embedded CTO engagement over roughly sixteen months, serving parents and their children on one shared account structure. The parent's subscription and billing ran entirely through RevenueCat on the parent's own account. The child's side used Firebase Anonymous Authentication with Custom Tokens instead of a full login, so the child's account carried no billing surface at all and the child was never shown, asked for, or able to reach a payment credential.

That costs more upfront than treating both users as one account, since you are building and testing two authentication paths instead of one. Most teams skip it under deadline pressure and regret it once a second device or a support ticket about "my kid saw my card number" shows up.

What to ask before you build this

If your app has any user under 18 who interacts with it directly while a parent holds the subscription, this separation is close to the only defensible architecture under POPIA. If every user is an adult managing their own subscription, a single account model is the right, simpler choice. Before a developer starts building, ask directly: does the child's session ever call the billing SDK, even indirectly? Is the payment method reachable from an account the child controls? Is there a documented legal basis for whatever the child's account does collect? If a developer can't answer those clearly, the custom software development needs another architecture pass before you build a subscription business on top of it.

Get the separation right and the rest of the billing integration is comparatively easy. Get it wrong and no privacy policy fixes an account that was never structured to keep payment data out of reach. Founders building anything with a minor as the direct user should treat this as an architecture decision made before the first line of billing code, not a policy written afterward.

Questions about subscription billing for apps with children

Does POPIA treat anyone under 18 as a child, unlike the US's 13-year COPPA cutoff?

Yes. POPIA sets its child threshold at under 18, not the 13-year cutoff used by the US's COPPA. Any app collecting or processing a South African user's data under that age needs a documented legal basis, not just an age-gate checkbox (MJ Kotze Inc, "Mobile App Legal Requirements in South Africa [2026]").

Do you need parental consent to process a child's data under POPIA?

Yes. Section 34 of POPIA prohibits processing a child's personal information unless a Section 35 exception applies. For a commercial app, the workable exception is prior consent from a competent person, meaning a parent or legal guardian, obtained and recorded before the child's data is processed.

Is passing Apple or Google app store review the same as being POPIA compliant?

No. Passing Apple or Google app store review checks the platform's own rules, not South African law. An app can clear store review and still fail a POPIA audit, and being POPIA compliant on its own does not automatically satisfy either store's separate child-safety requirements.

What does data minimisation mean for a child's data in an app?

It means collecting only what a child-facing feature actually needs: no behavioural advertising profiles built from a minor's activity, no unnecessary device or contact identifiers, and nothing retained past the point where the feature it supports stops using it.

How do apps let a child use the app without giving them the parent's payment method?

By separating the accounts entirely. The parent's account holds the payment method and the subscription; the child's account is created through a lightweight, credential-free sign-in with no payment fields anywhere in its interface, the same underlying pattern behind Apple Family Sharing or Google Family Link.

How much can a company be fined under POPIA?

The maximum administrative fine under POPIA is R10 million. South Africa has issued two fines to date, both at exactly half that ceiling: R5 million each, to the Department of Justice and Constitutional Development in 2023 and the Department of Basic Education in December 2024 (ClearComply, "Has Anyone Actually Been Fined Under POPIA? Real Cases in South Africa (2026)").

Does the Consumer Protection Act affect app subscription cancellations in South Africa?

Yes, for natural-person subscribers. Section 14 of the Consumer Protection Act governs fixed-term subscription mechanics in South Africa: a consumer can cancel on notice, and a subscription cannot be silently locked into renewal without that cancellation right being honoured.

This account split connects to broader questions covered in POPIA and multi-user account design for a children's EdTech app, and in structuring a GDPR and POPIA compliant architecture from the start.