Browser encryption & UI Components
Encrypt sensitive values in the page, against your tenant’s public key, so plaintext (a card number, an SSN) never touches your servers. You store and transmit only a portablekc: ciphertext — and only KnoxCall, holding the private key, can decrypt it. No API key is ever shipped to the browser.
This is how you collapse a payment/PII frontend toward PCI SAQ A.
1. Client-side encryption (@knoxcall/browser)
Your backend fetches a sealing bundle (the tenant public key + a key reference — no private material) and hands it to the page. Encryption is then a pure client-side operation with no network round-trip.
kc: value you produce here decrypts through /v1/decrypt, a Relay route-action, or a data-plane enclave.
2. Reveal to the browser without an API key
To show a user one decrypted value, your backend mints a single-use, payload-pinned capability token (see client-side reveal) and the page exchanges it once:3. Iframe UI Components (@knoxcall/react)
For the strongest isolation, capture and display data inside a cross-origin iframe served from a KnoxCall origin. The host page — and any XSS on it — never sees the raw PAN; your callback receives only the kc: ciphertext plus non-sensitive display bits (last4/brand).
<Reveal> is the mirror: it decrypts (or detokenizes) with a capability token and displays the value inside the iframe, so plaintext is shown to the user but never crosses into your JavaScript.
Which to use
| You need | Use |
|---|---|
| Seal a value your own form already holds | KnoxEncryptor.encrypt() |
| Never let your JS touch the PAN at all | <CardCollect> (iframe) |
| Show one decrypted value to a user | capability token + KnoxClient.reveal() or <Reveal> |
| Decrypt server-side / in transit | /v1/decrypt or Relay route-actions |