Overview

​

What Secure Elements is

• Card Reveal — show a user their own PAN, expiry, and CVV.
• Secure Card Input — collect a physical card and add it as a payment method on their account.
• VAN Reveal — show a user the account and routing number of their own virtual account number.

​

How it works

Your backend  →  mint client token  →  Your frontend  →  SDK mounts Fluz frame  →  callback with result

​

Prerequisites

• Your application is registered with Fluz. The scope required on your access token depends on which capability you’re minting a client token for:

  Purpose	Required scope
  reveal (Card Reveal)	CREATE_VIRTUALCARD
  tokenization (Secure Card Input)	MANAGE_PAYMENT
  van-reveal (VAN Reveal)	LIST_PAYMENT

• For a reveal token specifically, you also need an ACTIVE virtual card id, owned by the account you’re revealing, to pass when minting it.
• For a van-reveal token specifically, you also need a virtualAccountNumberId, owned by the account you’re revealing, to pass when minting it — the same id getSpendAccountVirtualAccountNumbers returns, and the same LIST_PAYMENT scope that call already requires.

​

Environments

​

Loading the SDK

<script src="https://secure-cdn.fluz.app/secure-elements/v0.3.0/index.global.js"></script>
<script>
  const { createCardViewer } = FluzSecureElements;

  const viewer = createCardViewer({
    /* ... */
  });
</script>

​

Mint a client token

POST {baseUrl}/v1/client-token
Authorization: Bearer <your Fluz OAuth access token>
Content-Type: application/json

{
  "purpose": "reveal",
  "virtualCardId": "<uuid>"
}

{ "clientToken": "<token>", "loadToken": "<token>", "expiresIn": 300 }

​

Styling fields

const viewer = createCardViewer({
  clientToken,
  loadToken,
  frameHostOrigin: "https://staging.secure.fluz.app",
  style: {
    color: "#1a1a1a",
    fontSize: "16px",
    fontWeight: "600",
    fontFamily: "Inter",
  },
});

• createCardViewer / createAccountViewer (reveal) — each field is its own frame holding a single value, rendered as one inline-block element, so these four properties apply directly to it.
• renderFieldsForTokenization (Secure Card Input) — the fields share one frame, each inside its own wrapper box. These properties apply to that wrapper, not the input text itself. See Box-model styling and Layout on the Secure Card Input page for the layout option this also unlocks.

• System fonts — common OS/web-safe stacks (system-ui, -apple-system, Helvetica Neue, Arial, Georgia, Menlo, and the generic monospace / serif / sans-serif keywords, among others). These render immediately, with no network request.
• Google Fonts — any family from the Google Fonts catalog ("Roboto", "Inter", "IBM Plex Mono", and so on), passed exactly as Google lists it. The SDK loads the font for you — you don’t need a <link> tag or @font-face rule.

const { SYSTEM_FONTS, GOOGLE_FONTS, isAllowedFontFamily } = FluzSecureElements;

isAllowedFontFamily("Roboto"); // true
isAllowedFontFamily("roboto"); // false -- exact, case-sensitive match required

​

Content Security Policy

frame-src https://secure.fluz.app;  # or https://staging.secure.fluz.app to test against staging
script-src https://secure-cdn.fluz.app 'nonce-<your-nonce>';  # or a hash, for the inline script that calls the SDK

<script nonce="<your-nonce>">
  const { createCardViewer } = FluzSecureElements;
  // ...
</script>

​

Security model

• Your OAuth access token never leaves your servers.
• The client token your frontend holds is opaque and single-purpose — it carries no card data and can’t be replayed for a different card or action.
• Card data is only ever readable inside Fluz-hosted frames, isolated from your page’s own JavaScript. Every frame is sandboxed (allow-scripts allow-same-origin allow-forms) with referrerPolicy="no-referrer" — the SDK never puts card data in the DOM outside of them.
• The frame only renders inside origins you’ve pre-registered with Fluz.
• Card data never reaches your servers or your page’s JavaScript — this is the condition most relevant to SAQ A eligibility under PCI DSS, alongside the other requirements SAQ A sets (e.g. not otherwise storing, processing, or transmitting cardholder data yourself). Your applicable PCI DSS obligations depend on your full cardholder data environment; confirm your scope with your QSA.

​

Next steps