SDK security
Published release: SDK 0.1.3 is publicly available on npm. Package installation does not activate new backend features.
- Run the credential client on the server only. Configure the exact API origin yourself; never accept it from a shopper. Redirects from the API are rejected so credentials are not forwarded to another origin.
- Authenticate customers and authorize cart/order ownership in your backend. A store key authorizes the integration, not every shopper who calls your route.
- Enforce exact trusted checkout origins, HTTPS, request-size limits, session/CSRF checks and per-user rate limits. The SDK’s origin validation does not replace application authorization.
- Persist cart attempts, serialize concurrent checkout creation and reconcile ambiguous results. Do not trust browser prices, success flags or returned session references without ownership checks.
- Keep customer data, private links and credentials out of logs. Safe SDK errors do not sanitize configuration or logs you create yourself.
- Verify signed raw-body events before effects and persist event deduplication. The optional agentic verifier is not a merchant subscription system or Stripe webhook handler.
No method changes fees, tax coverage, country approval, balance, reserve, refunds, recovery, debt or payout schedule. Individual sellers still request refunds for Kordiva approval; a key or SDK does not grant admin authority. Physical goods, deposits, Booking, Rent-a-Car and buyer subscriptions remain outside Individual digital eligibility.
Read-only catalog retry is not exactly-once checkout. Matching key prefixes are a local safeguard; backend record and eligibility checks remain authoritative. Production configuration and merchant host security require their own deployment review.
What the package boundary guarantees
Section titled “What the package boundary guarantees”Browser export resolution rejects imports of the credential-bearing SDK and Node webhook verifier. A real Next.js negative build tests this failure. Positive browser chunks are scanned for a server-only sentinel and SDK transport code. This does not prevent someone from manually hardcoding a secret in unrelated application JavaScript, rendering it as a prop, or exposing a public environment variable: keep those out of client source entirely.
The existing apps/api-integration demo is not a safe production template: it accepts a secret in browser state and sends it to an editable API origin. Its corrections are proposed separately; use this SDK’s protected backend examples instead.