May 2026 Changelog

May brought self-service merchant onboarding, wallet token migration via Stripe, and a set of vault enhancements driven by customer requests.

Self-Service Merchant Onboarding 

You can now create Merchants and submit Account Updater and Network Token onboarding directly from the Customer Portal without any support tickets, emails, or shared documents. Each Merchant supports its own configuration, so a single tenant can run multiple Account Updater and Network Token setups side by side.

Onboarding used to mean sending your details to support over email or a Google Doc and waiting for a handoff with no visibility into progress. The Portal replaces that with self-service forms for Merchant creation and per-network enrollment, plus status tracking for every service and network so you always know where an onboarding request stands.

Why does this matter?

1. You provision Account Updater and Network Tokens on your own timeline instead of waiting on a manual support workflow.
2. You get real-time visibility into onboarding status per service and per network, rather than emailing for updates.
3. Multiple Merchants under one tenant unlock separate Account Updater and Network Token configurations for teams with more than one business profile.

Return to Top

Wallet Token Migration through Stripe Forwarding 

You can now migrate wallet-based credentials into Basis Theory through the Stripe Forwarding API. The /connections/stripe-forward/tokenize endpoint accepts Apple Pay and Google Pay payment methods (DPANs) and ingests them as the matching Apple Pay or Google Pay resources, not just card tokens. See Tokenize a wallet DPAN for the full request shape.

Previously, the /connections/stripe-forward/tokenize endpoint only created card tokens, which left merchants with significant wallet volume unable to fully move off Stripe. Their stored wallet credentials stayed stranded, since the only alternatives were a file-based export that triggers Stripe risk reviews or simply leaving those tokens behind. Now those wallet credentials migrate through the same Forwarding path you already use, giving merchants a single, PCI-safe way to bring an entire wallet—cards and network tokens alike—into Basis Theory and complete the move off Stripe.

Why does this matter?

1. Merchants with heavy Apple Pay and Google Pay volume can now de-risk off a single provider without leaving wallet credentials behind.
2. Migration happens through the Forwarding path you already use, avoiding file exports and the Stripe risk reviews they trigger.

Return to Top

Network Token Enhancements 

Provisioning a Network Token from an existing token is more flexible this month. POST /network-tokens now accepts an inline expiration_month and expiration_year alongside a token_id or token_intent_id, so you can provision tokens whose stored card data is missing an expiration date, common for older tokens and tokens created through conversion reactors without first patching the underlying card token and without ever sending the PAN through your backend.

Why does this matter?

1. Merchants with large legacy wallets missing expiration dates can provision Network Tokens in a single call while staying out of PCI scope.
2. The card property now also returns the product code, giving you finer detail about the underlying card.

Return to Top

Encrypted Payloads for Token Intents 

POST /token-intents now accepts the same client-side encrypted payload that /tokens and /tokenize already support. Your frontend can encrypt card data with a Client Encryption Key, forward the opaque payload through your backend, and create a Token Intent without your servers ever touching plaintext card data.

This lets you combine client-side encryption with the pre-commit validation. Token Intents enable encryption of card data in the browser, validation against the intent, and conversion to a persistent token, all without your backend touching plaintext card data. The full intent lifecycle of validation to conversion into a persistent token behaves exactly as it does with plaintext input, and the three endpoints accept a consistent payload shape.

Why does this matter?

1. You can run pre-commit validation on a Token Intent while keeping card data encrypted end-to-end, with your backend out of PCI scope.
2. /tokens, /tokenize, and /token-intents now behave consistently, so the same encrypted payload works across all three.

Return to Top