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.
All notable changes to @dakota-xyz/cards-js are documented here. The format is based on Keep a Changelog, and this project adheres to Semantic Versioning. The documented style contract is covered by semver.

0.1.2

The first release on the public npm registry. No code changes.

Changed

  • Documentation moved to docs.dakota.xyz. The README links here, and the package homepage points at the Cards.js overview.
  • The package description no longer mentions PIN setup, which this version does not ship.

0.1.1

Added

  • invalid_theme error. theme values are validated at handle creation. A value that carries a CSS var() reference (case-insensitive) now throws immediately, with a named error, instead of failing the reveal opaquely. Custom properties cannot resolve inside the card-data processor’s frames, so frame styles must be concrete values. Note that the throw site moves: creating a handle with such a theme now throws, where it previously returned a handle whose reveal() later failed. In React, the throw surfaces to the nearest error boundary.
  • Dark-scheme apps get transparent frames automatically. Frame hosts declare color-scheme: light inline, matching the frame documents, so browsers no longer paint the value frames on an opaque white backdrop inside apps that declare color-scheme: dark.

Changed

  • Theming: the theme option’s concrete-value and font-availability constraints, and custom-markup guidance for keeping revealed widgets aligned when they are placed inline with text (a revealed field has no text baseline).

0.1.0

The initial release of the library.

Added

  • Secure card-detail display. Show the full PAN, CVV, and expiry inside processor-controlled frames that your code cannot read, keeping your web front end in PCI DSS SAQ A scope.
  • Deliberate reveal. Single-use sessions, a reveal window bounded by autoMaskMs and the session TTL (capped at 10 minutes), and an SDK-enforced auto-mask.
  • Backend-mints / browser-consumes session model. A single fetchSession integration point that forwards { sessionType, origin } to your backend. Your API key stays server-side.
  • Framework-free core — DakotaCards with cardDetails() handles, lifecycle state, and a small event set (ready, revealing, revealed, masked, expired, copied). A failed reveal attempt emits masked, so event-driven consumers always see the attempt end.
  • React binding (@dakota-xyz/cards-js/react) — <DakotaCardsProvider>, and <CardDetails> / useCardDetails. The hook’s state reports revealing, so custom UIs drive their loading treatment from the SDK.
  • Reveal loading state. reveal() swaps the card face to the frame side immediately. Empty value frames render as a quiet loading pulse (.dk-field__frame:not([hidden]):empty, restylable) until the card-data processor’s frames arrive. A failed reveal swaps back to the masked face.
  • Theming — a default stylesheet that paints the Dakota card face (charcoal gradient, DAKOTA wordmark, card-network mark, and a grain-textured disc, with self-hosted fonts), CSS custom properties on the documented DOM recipe, and a theme option whose text styles propagate into the value frames.
  • Internationalization — overridable strings for the masked face and the screen-reader announcements.
  • Accessibility — an SDK-injected aria-live region announces reveal and re-mask. It hides itself inline, so a custom stylesheet needs no rule for it.
  • Typed errors — DakotaCardsError with a stable code, a retryable flag, and an optional upstream diagnosticId.