May 2026 Summaries

Payment vaults are third-party services that securely collect and store customer payment details outside a merchant’s systems, providing non-reversible tokens that merchants can use with payment processors and other services. By separating payment data storage from processing, vaults can help merchants pursue multi-processor strategies, retain control over customer payment information, reduce dependency on a single provider, route transactions toward lower-cost providers, and limit the scope and expense of PCI-DSS compliance. Full-service payment service providers such as Stripe offer similar functions alongside broader operational support, including transaction routing and payment-method tools, but may charge more and limit merchants’ ability to use alternative providers or build revenue-generating services. Although merchants can implement their own tokenization and multi-processor routing systems, doing so places greater security, compliance, technical, and reputational responsibilities on them. Payment vaults are presented as particularly useful for growing businesses seeking flexibility to connect with processors, authentication providers, and other API-accessible payment services without waiting for platform-specific integrations.

After 15 years in payments roles at companies including CardinalCommerce, Visa, Spreedly, and DEUNA, the author argues that merchants often pursue payment optimizations without controlling the underlying data needed to measure and improve them. While orchestration can connect payment services, it may also introduce latency, fragmented data, and opaque failure points that make it difficult to diagnose performance issues. An example involving a merchant with 14 global brands found that network tokenization, account updater, and 3DS services were managed through separate providers, and centralizing their data identified nearly $2 million in annual savings while enabling a broader omnichannel credential strategy. The author contends that increasingly complex enterprise payment environments require independent, programmable control of sensitive payment data, particularly as automated and agentic commerce expands. Having joined Basis Theory, the author positions its vault-based infrastructure as a way for merchants to reduce vendor lock-in, improve authorization and renewal performance, support flexible payment strategies, and retain control over customer relationships and business-specific workflows.

April’s Basis Theory updates focused on improving platform reliability, data accuracy, and operational efficiency through a rebuilt BIN details pipeline, enhanced Account Updater results, broader proxy compatibility, and several bug fixes. BIN data now comes from a merged master dataset covering more than 50 weeks of card network history, with automated integrity checks and PCI-compliant DynamoDB delivery designed to prevent valid ranges from disappearing because of incomplete or incorrect weekly source files. Account Updater batch CSVs now include updated card metadata such as last four digits, fingerprint, brand, and expiration details for relevant PAN and brand-conversion updates, reducing the need for individual follow-up API calls. The proxy now accepts Latin-1 non-ASCII response headers from upstream APIs, preventing related 502 failures, while fixes addressed Firefox and LastPass conflicts affecting Web Elements, incorrect session permission handling for ID-based rules, and problematic blank access-rule container values in the portal.

Payment orchestrators route transactions among payment service providers to improve approval rates, reduce processing costs, and simplify the addition of new payment options, often using factors such as customer location, payment method, and provider fees. While they can quickly improve payment performance, third-party orchestration platforms may create challenges involving security requirements, access to settled funds, limited control over routing rules, and difficulty accommodating complex commercial agreements. Merchants may outgrow these services when orchestration fees exceed the value provided, when they need greater resilience against partner outages, or when security and checkout-experience requirements demand more control. The text suggests that larger businesses can address these issues by building in-house payment decisioning engines and using a secure, processor-independent token vault to store credentials, enabling flexible routing while reducing dependency on any single processor or orchestration provider.

Credit card information is structured to route, authenticate, and secure payment transactions, with the Primary Account Number (PAN) identifying the card network, issuing institution, individual account, and a final check digit used to detect entry errors. The first six to eight digits form the Bank or Issuer Identification Number, whose first digit, the Major Industry Identifier, signals the card network or industry category, while the remaining PAN digits identify the cardholder account. PCI DSS separates payment data into Cardholder Data, which may be stored with appropriate controls, and Sensitive Authentication Data, such as CVV/CVC codes, full magnetic-stripe data, and EMV chip data, which merchants generally cannot retain after authorization. Security codes help validate card-not-present purchases, while EMV chips improve in-person security by generating a unique transaction code rather than relying on the static data held on magnetic stripes. The material emphasizes that organizations handling payment information face compliance and security responsibilities, and presents tokenization as an approach for processing payments without retaining raw card data and expanding PCI DSS scope.

Payment tokenization replaces sensitive card data with unique identifiers while storing the original data securely in a token vault, allowing merchants to process payments without exposing cardholder information in their own systems. Unlike encryption, which reversibly scrambles data and can be compromised if keys are stolen, tokenization creates identifiers with no mathematical relationship to the underlying card number and can protect data both in transit and at rest. The process generally involves collecting payment information through a provider-hosted form, storing it in the provider’s vault, and using tokens to authorize transactions through selected payment service providers (PSPs), including updates to saved payment details. Token types can be format-preserving, random, single-use, or multi-use, with different tradeoffs for legacy compatibility, security, guest purchases, subscriptions, and saved payment methods. By preventing cardholder data from reaching merchant systems, tokenization can substantially reduce PCI-DSS compliance scope, while third-party, PSP-agnostic tokenization can let merchants retain control of their tokens and route transactions among multiple PSPs. The Passes example illustrates how this flexibility can support cascading payment strategies for businesses seeking to improve authorization rates, reduce processing costs, and avoid dependence on a single provider.

Online merchants face pressure from payment-processing fees, customer preferences, security requirements, and checkout abandonment, particularly as they expand internationally and operate on thin margins. The discussion emphasizes that offering local payment methods can improve overseas conversion, while retaining control over customer payment data supports subscriptions, repeat purchases, and flexibility to use or change payment providers. It argues that relying on a single payment service provider can create risks such as limited payment-method coverage, inaccessible payment tokens, and higher long-term costs from fees, chargebacks, and currency conversion. Merchants may therefore adopt multi-processor payment systems and independent payment-data vaults to route transactions more efficiently, reduce friction, improve approval rates, and negotiate better economics. Secure third-party storage can also help businesses limit exposure to sensitive personal data and reduce the time and expense of maintaining PCI-DSS compliance as transaction volumes grow.

PCI-DSS applies to physical as well as digital handling of payment data, requiring merchants to tightly control access, storage, transmission, retention, and destruction of paper records containing cardholder information. Merchants may store limited data such as the primary account number, cardholder name, service name, and expiration date when necessary, but they must never retain full magnetic-stripe data, security codes such as CVV/CVC, or PIN data, and PAN and CVV/CVC should not be kept together. Paper collection can arise during power or connectivity outages, telephone orders, manual card-imprint transactions, and physical donation or membership forms, but it should be avoided where possible and records should be processed promptly and irreversibly destroyed. Authorized personnel must use secure storage, documented audit trails, approved transmission methods, and established procedures rather than informal notes, emails, spreadsheets, or unsecured forms. Online travel agencies face particular exposure because high-value bookings and multiple third-party suppliers can encourage insecure manual handling, expanding both breach and compliance risks. Clear policies, restricted access, secure destruction practices, and tokenized payment systems can reduce reliance on paper and help limit PCI compliance scope.