1. Collect encrypted card data
Load the Evervault JavaScript SDK directly from its CDN. The Card component runs in an Evervault-hosted iframe, so PAN and CVC are encrypted before they reach your parent page or backend.index.html
/api/cards endpoint should accept Evervault-encrypted number and cvc values plus expiry month/year metadata. Allow only those expected fields, reject plaintext or malformed ciphertext, and validate the expiry metadata server-side. Client-side validation is not a security boundary.
Store the encrypted PAN only under your reviewed retention policy. Treat CVC as transaction-specific input: do not retain it after authorization, even encrypted. Do not decrypt PAN or CVC in your automation backend or log submitted values.
2. Create Browser Tokens
For each checkout, send theev:... ciphertext returned by Card Collection (card.values.card.number and card.values.card.cvc) to your backend. Immediately before starting automation, send those same ciphertext strings as data[].value to Evervault’s POST /browser-tokens API. You do not need to decrypt or re-encrypt them first.
Evervault returns fresh, short-lived, format-preserving PAN and CVC placeholders plus separate proxy credentials. Browserbase fills the placeholders, not the ciphertext or original values. The reveal policy controls disclosure to a destination, not authorization to charge the card. For later transactions, you may reuse a stored encrypted PAN under your reviewed retention policy, but collect CVC again if required.
proxyConfiguration.hostname, port, username, and password. Keep those credentials server-side and use them only to create the matching session.
3. Trust the Evervault CA
Evervault’s proxy replaces token values in HTTPS requests. Download the Evervault CA certificate, save it as a PEM file, and upload it to the Browserbase project once:4. Launch Browserbase through Evervault
Pass the returned proxy credentials as an external Browserbase proxy and reference the uploaded CA certificate. The example disables Browserbase logs and recordings, keeps certificate validation enabled, and uses a bounded session timeout. Replace the expiry and confirmation selectors with the merchant’s actual fields and success state.createCheckoutSession or create_checkout_session; never fetch the original card values for this step. Evervault reveals the originals only when the request goes through its proxy, matches an allowed hostname, and occurs before the token expires. After authorization, discard the CVC token, ciphertext, and matching proxy credentials.
Troubleshooting
Certificate errors
If HTTPS pages fail withERR_CERT_AUTHORITY_INVALID, verify that the Evervault CA is a valid PEM certificate, that it is uploaded to the same Browserbase project as the API key, and that its ID is present in proxySettings.caCertificates. Do not set ignoreCertificateErrors.
The checkout rejects a token
Confirm that the token category matches the field (card.number or card.cvv), that the token has not expired, and that the browser request reaches a hostname in permissions. Include the PSP or iframe hostname when the merchant does not process card data directly.
Production checklist
- Store an Evervault-encrypted PAN only under your reviewed retention policy. Do not retain CVC after authorization, even encrypted.
- Create tokens immediately before a checkout and set the shortest workable TTL.
- Allowlist exact merchant and PSP hostnames.
- Keep token values and proxy credentials out of logs, prompts, screenshots, and recordings where possible.
- Use a project-scoped Browserbase CA certificate and keep certificate IDs in configuration.
- Dispose of token values and proxy credentials after the session ends.
- Validate the complete flow with your security and compliance teams.