Tokenizer

A hosted iframe payment form that keeps card data off your server. Drop it into any web page and get back a one-time-use token to charge or vault.

The Tokenizer is a small JavaScript library plus an iframe-hosted card form. Your site loads the library, places the form, and listens for a token event. The card number never touches your server — you receive a token in place of it, and call moat's APIs with the token instead of the PAN.

Why tokenize

Tokenization keeps you in SAQ A PCI scope (the smallest), meaning drastically less paperwork and annual audit overhead. If your site ever touches card numbers directly — even briefly in JavaScript — you move to SAQ A-EP, which is a very different beast.

Include the library

<script src="https://sandbox.fluidpay.com/js/tokenizer/v1/tokenizer.js"></script>

In production, swap sandbox.fluidpay.com for app.fluidpay.com.

Initialize

const tokenizer = new Tokenizer({
  apikey: "pub_YOUR_PUBLIC_KEY",
  container: "#payment-form",
  submission: (resp) => {
    if (resp.status === "success") {
      // resp.token is a one-time-use payment token
      document.getElementById("tokenValue").value = resp.token;
      document.getElementById("checkoutForm").submit();
    } else {
      console.error("Tokenization failed", resp);
    }
  }
});

Options

Option	Type	Description
`apikey`	string	required. Your public key (`pub_...`). Safe to ship in browser code.
`container`	string	required. CSS selector where the iframe form mounts.
`submission`	function	required. Callback invoked when the user submits the form. Receives the token (or an error).
`settings`	object	Optional. Controls which fields are rendered and their styling.
`onLoad`	function	Called once the iframe has loaded.
`onPaymentChange`	function	Called when the user selects between card and ACH, or when a card brand is detected.

Settings

The settings object controls the fields rendered and their visual style. Common patterns:

settings: {
  payment: {
    types: ["card", "ach"],               // which method selectors to show
    card: {
      strict_mode: true,                   // reject invalid BIN format up front
      show_address: true,                  // render billing address fields
      show_zip: true
    },
    ach: {
      show_account_type: true
    }
  },
  style: {
    body: { color: "#222" },
    input: {
      border: "1px solid #D0D5E0",
      borderRadius: "8px",
      padding: "10px 12px",
      fontSize: "15px"
    },
    ".invalid": { borderColor: "#E53E3E" }
  }
}

Token lifecycle

A token returned by the tokenizer is single-use and short-lived:

Single use — once charged or vaulted, the token is consumed.
10-minute TTL — unused tokens expire after 10 minutes.
Not sensitive to leak the way a PAN is — a token cannot be charged without a valid API key, so embedding it in URLs or logs is lower-risk than a card number. It is still good hygiene to treat tokens as sensitive and not log them.

Using the token

Pass the token as the payment_method in a transaction or customer create call:

{
  "type": "sale",
  "amount": 1999,
  "payment_method": {
    "token": { "id": "tok_01H9XK..." }
  }
}

Events and error handling

Event	When
`onLoad`	Iframe has loaded.
`onPaymentChange`	Payment type switched, or card brand detected.
`onValidityChange`	Form validity state changed. Useful for enabling/disabling your submit button.
`submission`	User submitted. Receives success token or failure with field-level errors.

Do not bypass the iframe

The whole point of the tokenizer is that card data lives in a moat-controlled frame on a moat origin. Do not render your own card input and submit it through the tokenizer's API — that moves you back into extended PCI scope and defeats the design.