Normalize a merchant of record's payment into a standard format
Normalizes a merchant of record's raw payment payload into a standard, provider-independent shape, so downstream transaction calls do not need to know each provider's format. Name the merchant of record in `provider` and pass its raw payload in `data`. For Xsolla that payload is the `payment` webhook body, which must include the card BIN.
Authorization
api-key In: header
Request Body
application/json
Look up provider request
TypeScript Definitions
Use the request body type in TypeScript.
A merchant of record's raw payment payload to normalize into k-ID's standard format.
Response Body
application/json
application/json
curl -X POST "https://example.com/transaction/lookup-provider" \ -H "Content-Type: application/json" \ -d '{ "provider": "xsolla", "data": {} }'{ "provider": "xsolla", "invoiceId": "2110445753", "payerEmail": "parent@example.com", "instrument": "card", "funding": "credit"}{ "error": "INVALID_INPUT", "errorMessage": "unsupported payment provider"}Start screentime POST
Marks the start of active screentime on this product. While screentime is active, k-ID delivers real-time webhooks - `Screentime.BreakReminder`, `Screentime.LimitWarning`, and `Screentime.LimitReached` - that fire at the moment a threshold is crossed, not only when usage ends. Status semantics: * `accepted` - screentime was started, or a retried call against an already-active session was absorbed idempotently. * `replaced` - a different `id` was sent while screentime was already active for this `sessionId`; the prior screentime was automatically ended and its duration counted toward today's screentime usage. Use this to recover when the prior screentime was never explicitly ended (e.g. after an app or device restart). Only one active screentime is supported per `sessionId` at a time. Calls must be made in real time - the `timestamp` value cannot be more than 5 minutes in the past.
Submit completed money-flow transactions for a session POST
Submit one or more completed purchases for a k-ID session. Each event records what was bought, what it cost, and whether the charge went through. Use this endpoint after a purchase completes, including each renewal of a recurring one. Set `status` to `failed` for a charge that was attempted and did not complete, so a parent can tell the two apart. Events are processed independently. The response carries a per-event status: * `accepted` - the purchase was recorded. Resubmitting an event whose `id` was already accepted is a safe no-op: it counts as `accepted` again and is not recorded twice, so retries after a network failure won't double-count. * `rejected` - the purchase failed validation; the `reason` identifies which rule. The whole batch is rejected when the session does not exist or is revoked.