Skip to main content

Transactions

Transactions let a parent see and control what their child buys in a connected app. Your product reports purchases to k-ID and, where you want a parent in the loop before a charge, asks for their approval first. k-ID records the purchases, holds the approval state, notifies the parent, and tells you the outcome. What the money does is still your product's decision.

Purchases are reported per child per session, so a parent reads one running history of what their child bought in your product rather than a per-device or per-receipt view.

What the parent gets​

Two capabilities sit under Transactions, and a product can use either on its own:

  • Purchase visibility. Your product reports completed purchases and k-ID surfaces them to the linked parent, both as a per-child Purchases view in Family Connect and as a line in the recurring activity digest. This is reporting: nothing about it blocks a purchase or asks anyone to act.
  • Purchase approval. Before a specific charge, your product asks the parent to approve it. k-ID holds the request, notifies the parent, and returns their answer as a webhook. This is the part that puts a parent in front of a purchase.

The two are independent. A product can report purchases without ever asking for approval, ask for approval on some purchases and report all of them, or use approval alone.

The boundary​

k-ID records purchases, holds approval requests, notifies the parent, and reports the outcome. Your product decides what a purchase is, whether to charge, and when to ask.

k-ID never processes a payment, moves money, or blocks a charge. It doesn't witness the transaction. When you ask a parent to approve a purchase, k-ID returns their decision; whether an unanswered or denied request stops the charge is enforced in your product.

Reporting a purchase​

Each purchase is a flat record: a title and optional description shown to the parent as-is, an amount in the currency's minor units, a currency, the timestamp it completed, an optional url where the parent can manage it (for example, to cancel a subscription), and a status of successful or failed.

Reporting failed charges matters: it lets a parent tell a purchase that went through from one that was attempted and didn't. A subscription renewal is reported as a purchase each time it charges.

Purchases also feed the activity a trusted adult reads, so the amounts appear in the recurring digest and the Purchases view. See the transactions integration guide for the endpoint and its per-event result shape.

Asking a parent to approve a purchase​

When you want a parent's decision before charging, your product opens an approval request against the session. k-ID notifies the parent, who grants or denies it in Family Connect, and the outcome arrives as a Transaction.PurchaseApprovalResult webhook carrying approved, denied, or expired.

  • Ask before you charge. The request is a gate you place in front of the purchase, not a receipt after it. Complete the purchase only once the approval arrives.
  • A request that goes unanswered expires after 24 hours. Expiry is a normal outcome reported through the same webhook, not a failure. The player can be offered the purchase again.
  • The request carries the deadline. Treat the expiresAt the request returns as the point past which the answer can no longer come, rather than waiting on the webhook indefinitely.

See Requesting approval for the request and webhook shapes.

Transactions and payment-as-verification​

A completed card payment can also stand in for parental consent, where the jurisdiction recognizes it. That's payment-as-verification, a separate capability that rides on the same Transactions configuration. It's about consent, not visibility, and it's covered on its own page.

Enabling transactions​

Transactions are off by default and enabled per product in Compliance Studio. Until it's on, the transaction endpoints return FEATURE_DISABLED. See the transactions integration guide for the setup steps.

Next steps​