SDK — Overview

Lunixi publishes two SDK families. Both rest on the same platform contract; what differs comes from the environment they run in.

Family	Where it runs	Page
Web	The browser — 7 separate bundles	Web SDK
Mobile	iOS · Android — Flutter and React Native bridges	Mobile SDK

True of both

🚫

The decision is never made on the client. An SDK produces and carries evidence; the server decides. Even a fully compromised client cannot fake a favourable outcome, because it is not the thing producing the outcome.

Not fail-open — a failed call does not silently return a pass; it throws. You own the fallback.
Environments are separated by key — the SDK talks to whichever environment its key was issued for. There is no separate configuration flag.
A secret is never present on the client — not in the browser, not in the mobile bundle.
The same error envelope and the same requestId correlation. → Error Handling

Why authentication differs

This is the one real difference:

	Web	Mobile
Anchor of trust	The `Origin` header — set by the browser, unforgeable from the page	Device attestation and token bindings
Key	Publishable key (`mk_{environment}_pk_…`)	Session context plus the native collector

In a browser Origin exists and cannot be forged, so a publishable key plus an origin allow-list is a sufficient anchor. On mobile there is no Origin — so trust comes from the device proving itself, and from an action token bound to the device, the session and the challenge.

Which to pick

Need	Family
Payment form, customer portal, pricing table	Web
A card field without ever touching card data	Web — Hosted Card Field
Identity verification in a browser	Web — KYC SDK
Transaction-time risk measurement in a mobile app	Mobile — Mobile Threat
Identity verification in a mobile app	Mobile — Native KYC (NFC plus attestation)

Where to start

Web SDK Overview — loader, the four integration modes, the authentication table
Mobile SDK Overview — the bridge/native split and the packages

Overview