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 is built so that your app displays sensitive card data without that data ever being exposed to your app. This page explains the guarantees that follow from that, the responsibilities that stay with you, and how to report a vulnerability.

​
Card data is never in your reach

The full PAN, CVV, and expiry render inside frames that Dakota’s card-data processor controls. Those frames are cross-origin: your JavaScript, your servers, and Dakota’s own application code cannot read their contents. Your page positions and sizes the frames and styles their text, but the values themselves live only inside the frames, and they go straight from the card-data processor to the cardholder’s screen. The sensitive values never touch your DOM, your network, or your storage, so integrating Cards.js keeps your web front end within PCI DSS SAQ A scope.

​
Deliberate reveal

Details show only on an explicit action, and only briefly:
  • Single-use sessions. A session authorizes one reveal and is consumed by it. There is no reusable, long-lived credential in the browser. Each reveal mints a fresh session.
  • A bounded reveal window. A successful reveal is time-boxed. The window is the smaller of any autoMaskMs you set and the session’s time-to-live, and the TTL is itself capped at 10 minutes. Details cannot stay revealed indefinitely.
  • SDK-enforced re-mask. When the window ends, the SDK tears down the value frames and restores the masked face itself. It does not depend on your code to hide the data again.

​
Your backend mints, the browser consumes

Your API key stays on your server, which mints each session only for a card the signed-in user owns. The browser only ever holds a single-use session token. See Secure card data.

​
Keep session tokens out of your telemetry

The card-data processor’s frames receive the session token in their URL, as a session query parameter. The SDK never logs the token, but tools on your page that record resource or frame URLs can capture it: real-user monitoring, session replay, and error tracking. Configure those tools to drop or redact the session parameter for the frame origins listed in Network & CSP.

​
No telemetry

Cards.js makes no network calls except those required to display card data: it loads the card-data processor’s reveal frames. It ships no analytics and no error reporting, and it never logs session tokens. The library sends nothing about your cardholders or your integration anywhere.

​
Reporting a vulnerability

We take the security of Cards.js seriously. If you believe you have found a vulnerability, report it to us privately, so that we can investigate and fix it before it is publicly disclosed. Email security@dakota.xyz with:
  • a description of the issue and its potential impact,
  • the affected version(s) of @dakota-xyz/cards-js,
  • steps to reproduce, or a proof of concept, if you have one.
Do not open a public issue, pull request, or discussion for a suspected vulnerability, and do not disclose it publicly until we have had a reasonable opportunity to respond.

​
What to expect

We will acknowledge your report, keep you informed as we investigate, and tell you when a fix is available. We ask that you give us a reasonable window to fix the issue before any public disclosure, and that your testing does not access, modify, or exfiltrate data that is not yours. This project does not operate a paid bug-bounty program, and no bounty or reward is promised for a report. We are grateful for responsible disclosure regardless.