August 2026 Changelog

August focused on AI agents paying within cardholder-approved limits across Visa, Mastercard, and now Stripe, all through one API.

We're also sharing two upcoming changes to Reactors and Proxy transforms. You won't be able to create new ones on node-bt after Oct. 5, 2026, and Basis Theory will soon reject code that contains plaintext secrets. Now is a good time to move to Node.js runtime images and scan your code.

Rounding out August are fixes for Proxy query parameters, network token suspension, white-label Elements embedding, and webhook destinations.

Let AI Agents Pay Within Limits You Control

You can now give AI agents bounded, auditable spending power through one API, whether the payment runs on a card network program or on Stripe.

Agentic Payments is now built on the Shared Payment Model. Payment methods are the vaulted cards an agent can pay with. Allowances are human-readable mandates with an amount, a plain-language description of what the spending is for, and an expiration. Credentials are single-purchase tokens minted on demand against an allowance, and each one permanently draws its amount from the allowance when it's created. The merchant on an allowance is now optional, so you can create an allowance before the agent knows where it will buy. New test tenants also have Agentic Payments enabled automatically.

The model works the same way across payment rails. With Visa Intelligent Commerce and Mastercard Agent Pay, credentials are bound to network-held mandates and the cardholder verifies with a passkey or one-time code. Stripe Shared Payment Tokens (SPTs) are processor-level tokens scoped to a single recipient that require no cardholder verification step, and you can retrieve them as a raw SPT or as a Machine Payments Protocol (MPP) credential. The API exposes each rail's verification requirements and credential format as properties, so your integration doesn't need to hardcode assumptions about a specific network.

The previous Agentic Commerce API is deprecated. If you're on it, the legacy guide covers your current integration while you move to the Shared Payment Model.

Why does this matter?

1. A single integration supports Visa, Mastercard, and Stripe.
2. Allowances set explicit, cardholder-approved limits on what an agent can spend.
3. Stripe SPTs offer a quick way to start accepting agentic payments with merchants that already use Stripe.

Read the Agentic Payments overview to get started.

Return to Top

Avoid Future Interruptions by Moving Off node-bt: Action Required by Oct. 5, 2026 

Starting Oct. 5, 2026, you can no longer create new Reactors or Proxy transforms on the node-bt runtime. Node.js runtime images give you stronger isolation, current Node.js versions, and runtime logs, and all new runtime features will ship there.

Moving over also removes limits you may be working around today. node-bt runs Node.js 16 and only supports whitelisted dependencies. Node.js runtime images run Node.js 22 or 24, support any npm package, and let you configure timeouts, resources, and warm instances. Dependencies are scanned at deployment and continuously after, not only for a managed list. See the full runtime comparison for every difference.

What's changing?

After Oct. 5, 2026, Basis Theory will stop accepting requests to create a Reactor or Proxy transform with the node-bt runtime. Your existing node-bt Reactors and Proxy transforms will continue to run, and you can still update them. This is the first step. We plan to stop running node-bt code altogether in the future, so we strongly recommend migrating now to avoid interruptions later.

What you need to do before Oct. 5, 2026:

1. Use a Node.js runtime image (node22 or node24) for every new Reactor and Proxy transform.
2. Identify your existing node-bt Reactors and Proxy transforms and plan their migration.
3. Move each resource's code, dependencies, permissions, and configuration to a Node.js runtime image, then test and roll it out.

Learn more about Node.js runtime images, and follow the migration guide for each step.

Return to Top

Keep Credentials Out of Your Reactor and Proxy Code 

You can now check your Reactor and Proxy transform code for plaintext secrets before you deploy it. Soon, Basis Theory will reject changes that contain them, so now is the time to find and remove any hardcoded credentials.

Call POST /function-source/validate with a Management API key to scan your code. It detects private keys, known credential formats such as AWS keys, Stripe secret keys, GitHub tokens, and Basis Theory API keys, static Basic or Bearer authorization values, and string literals assigned to names like apiKey, password, or client_secret.

The response shows whether a secret was detected, which categories were found, where they appear, and a redacted copy of your code. Test and sandbox credentials are treated the same as production credentials.

When enforcement begins, create, update, and patch requests for Reactors and Proxy transforms whose code contains a secret will return a 400 validation error. To get ahead of it, move sensitive values into the encrypted configuration object and read them at runtime through req.configuration.

Why this matters?

1. Credentials stay out of source code, where they can leak through copies, exports, and code reviews.
2. You can call the validate endpoint from CI today and clean up your code before enforcement begins.

Learn more in the Secret Scanning documentation.

Return to Top

Bug Fixes 

Processors Receive Query Parameters Exactly as You Send Them

The Proxy no longer rewrites query parameters that have no value. A request with ?ABC is now forwarded as ?ABC instead of ?ABC=, which fixes integrations with processors that treat the two forms differently. The fix is enabled for all tenants.

Predictable Errors When Suspending a Network Token During Deletion

Suspending a network token while it's being deleted now returns a controlled error instead of a 500 or 503. Previously, this race could leave a partial record behind that prevented the same card from being tokenized again in a sandbox tenant.

Embed White-label Elements Anywhere on Your Domain

White-label Elements served from a custom hostname such as js.example.com can now be embedded on the root domain (example.com) and all of its subdomains. Custom hostnames must still include a subdomain.

Webhook Events Only Go to Public Endpoints

Creating or updating a webhook now fails if its URL points to, or resolves to, a non-public address such as a loopback, private, or link-local IP. Existing webhooks that target public HTTPS endpoints are unaffected.