session_id from your server, submit a card, and confirm the resulting token — all without building a browser integration first. Reach for it when you want to verify a session from your backend before wiring up the SDK in your own application.
The workbench covers four flows, exposed as tabs at the top of the page: Card Tokenization, CVC2 Refresh, Card Elements, and 3DS. This page walks through the default Card Tokenization flow; the other tabs consume the same session and backend configuration.
Prerequisites
Asession_id from your backend — see the Guardian and Commerce v2 examples on the right.
Steps
Open the workbench
Visit https://demo.hellgate.dev/card. The page loads the same Web SDK you would embed in your own application.
Set the Backend Service URL
Use the Backend Service URL dropdown at the top of the page to match the environment that issued your session.There are built-in options (e.g. Sandbox (Shared Commerce v2)), which target the Test tier of the shared Hellgate Commerce v2 platform.For any other deployment — a dedicated Commerce v2 cluster or a Guardian cluster — enable the Custom URL toggle and enter the base URL of your backend (for example
https://<your-cluster>.on-hellgate.cloud).(Optional) Adjust form options
The remaining controls change how the SDK renders the card form. Leave them at their defaults unless you want to preview a specific layout:
- Schemes — restrict the accepted card networks.
- Card Layout — render the card fields as Single-line or Multi-line.
- Expiration Fields — Combined month/year field or Separate fields.
Next steps
Once the workbench flow succeeds, port the same session-plus-SDK pattern into your own application:- Web SDK Overview — initialize the SDK and render the card form.
- Web SDK API — detailed handler and event reference.