Child IAP needs parental consent and spending caps

What it is

When the account or device is used by a minor, IAP cannot rest on the child tapping confirm. Parental consent and caps means each capture, or each time window of captures, goes through a parent-side auth, with settable amount limits (per capture, day, month). It is not anti-shoulder-surf on a pay page, and not adult step-up on large amounts. The subject is a child; the mechanism is a guardian gate.

Why it happens

Children treat purchase as an in-game act and do not model legal tender leaving a card. Biometrics that are the child’s face, or a parent’s fingerprint stored “for convenience,” make the gate empty. A store password cached for “15 minutes without a code” allows a streak in one session. Caps bound the loss even if the gate is bypassed. Consent must reach a parent device or account, not a “I am the parent” control the child can tap on the same screen. On failure, buying stops—it does not degrade to ungated pay.

Studying it

Run IAP on a child account or child-configured device. Compare no gate, device passcode, parent confirm on another device, plus caps. Watch whether unauthorized buys complete and whether the parent is notified.

Independent variables: gate type, password-free window, cap granularity, whether the child can complete “parent” confirm on-device. Dependent variables: unauthorized completes, delay until the parent finds out, whether a genuine parent-proxy buy still passes.

Real children in the lab need ethics review. Role-play is allowed; do not treat it as child-behavior data. Store-system gates and in-app gates must be tested apart; the app must not switch the system gate off.

Where it stops holding

Unknown age cannot treat every user as a child, but first IAP can use a stricter gate and lead into family setup. School or shared-iPad MDM outranks in-app settings. An adult account a child is playing on is a session and lock-screen problem; caps will not help unless Family Sharing is on. Age thresholds differ by region; gate triggers follow local law, not one hardcoded age.

Applying it

• Under a minor configuration, IAP goes through parent approval on a parent device or a separate parent passcode—not a child-tappable dialog pretending to be the parent.
• Offer per-capture / day / month caps; over cap must re-ask, not fail silently as “payment failed.”
• Turn off “short window, many purchases without a password,” or shrink it to one transaction.
• Verify: a child role cannot complete without approval; the parent device gets the request and can refuse. After a daily cap, a second buy over the cap re-asks rather than capturing.

Related

• Within the group: H7.15.1 Virtual currency top-up vs spend rates must be calculable · H7.15.2 No-refund rules for virtual goods must be disclosed before purchase · H7.15.4 Probability items must disclose drop rates
• Adjacent: W10.06 Minor protection and real-name · H7.11 Payment security interaction · P4.05 Children and age-appropriate design
• Search terms: parental gate · Ask to Buy · child IAP