Skip to main content
Cards is available in sandbox only while we finish development. Dakota enables Cards per account. The Cards endpoints are in the API reference, marked Sandbox only. Endpoints, fields, and flows can still change before release.
Cards.js renders card values inside iframes served by Dakota’s card-data processor. If the page that hosts a reveal sets a Content-Security-Policy — which we recommend — you must allow those frame origins, or the values will fail to load.

​
What the SDK connects to

  • Frames load from the card-data processor’s embed origin, listed below. This is the only cross-origin network activity the SDK introduces.
  • No extra connect-src is needed for the SDK itself. Your own fetchSession call to your backend uses whatever origin your backend lives on. Allow that origin under your existing policy, as you would any first-party API call.
  • No extra img-src or font-src is needed. The default card face self-hosts its fonts from your own origin — they ship inside the package — and the SDK loads no remote images.

​
frame-src origins per environment

Allow the origin that matches the environment you construct DakotaCards with:
These origins are environment data that can change between releases. Treat this table as the value for the version you install. Check it again when you upgrade, rather than hard-coding the value elsewhere.
A policy for a production page that reveals cards looks like this:
For a sandbox build, use https://sandbox.lithic.com instead. If your app uses both environments, list both origins in frame-src. Frames from these origins carry the session token in their URL. If your page runs monitoring, session replay, or error tracking, keep the token out of it.

​
Protecting your own reveal page (frame-ancestors)

The origins above control what your page may embed. To stop a third party from embedding your reveal page and tricking a cardholder into revealing details inside a hostile frame (clickjacking), set frame-ancestors on the responses that serve your reveal UI:
Use 'none' if your reveal page is never meant to be framed, or list the specific parent origins that legitimately embed it. This directive controls who may frame you. It is independent of the frame-src allowlist above.

​
HTTPS is required

The page that hosts a reveal must be served over HTTPS (a secure context). The card-data processor’s frames do not operate on an insecure origin, and card data must never cross an unencrypted connection. This applies in local development too: serve your development app over HTTPS.