August 2026 Summaries

Apple Pay credentials are often stored within a payment service provider’s proprietary vault, creating switching costs and limiting merchants’ ability to route payments across processors. Decoupling moves Device and Merchant Primary Account Numbers into a merchant-controlled, processor-neutral PCI DSS Level 1 vault, allowing encrypted Apple Pay payloads to be securely routed to compatible processors while typically reducing the merchant’s PCI exposure. Benefits include credential portability, greater negotiating leverage, multi-processor routing for cost, approval rates, geography, or redundancy, and direct management of Apple token lifecycle updates and associated customer payment metadata. The proposed transition progresses from a fully PSP-coupled implementation to a hybrid model for new Apple Pay credentials, followed by export and migration of eligible legacy credentials—primarily DPANs—and finally a fully decoupled architecture in which processors become interchangeable proxy destinations. Existing subscriptions can continue operating through the original PSP during the hybrid phase, while MPAN migration remains dependent on processor and network support; merchants are advised to confirm that target processors accept decrypted Apple Pay credentials before deployment.

Merchants commonly change or add payment service providers (PSPs) to reduce fees, gain capabilities, expand into new markets, or improve transaction performance, but migrations can be delayed and costly when the outgoing processor controls stored customer card data and its associated tokens. Using an independent third-party tokenization provider to store cardholder information in a secure payment vault can make tokens portable, allowing merchants to share data with selected processors without handling sensitive payment information directly. This approach can reduce PCI compliance scope, avoid dependence on a single provider, and support multi-processor strategies that use intelligent routing to improve authorization rates, lower costs, and strengthen merchants’ negotiating leverage. The example of Maxio illustrates how portable tokens enabled it to update payment infrastructure without the potentially substantial costs and disruption associated with processor-controlled data.

Basis Theory’s summer platform releases include the general availability of Web Elements v3, asynchronous Reactors on its modern runtimes platform, a new Agentic Payments API, Customer Portal SSO improvements, Apple Pay sandbox support, and easier Java SDK distribution. Web Elements v3 rebuilds checkout fields as self-contained iframe bundles to improve loading and tokenization performance, while adding a combined card field, co-badged card selection, and custom-domain hosting. Reactors can now run asynchronously with durable queued execution and result retrieval, supporting Node 22 and Node 24 alongside isolation, dependency scanning, and concurrency controls. Agentic Payments replaces the prior Agentic Commerce model by allowing customers to approve limited spending allowances from which AI agents can mint single-use credentials across supported payment rails, with balance tracking intended to prevent overspending. The Customer Portal’s identity provider configuration and login flows were modernized, Apple Pay sandbox tokens can now be tested end to end in Test Tenants, and the Java SDK is available through Maven Central without requiring GitHub Packages authentication.

Businesses that store, process, or transmit payment-card data must annually demonstrate PCI DSS compliance, generally through a Self-Assessment Questionnaire (SAQ) or, for many Level 1 organizations, an independently audited Report on Compliance (ROC), followed by an Attestation of Compliance submitted to the relevant acquirer, payment provider, or card brand. The appropriate SAQ depends largely on whether payments are card-not-present or card-present and on how extensively payment functions are outsourced: SAQ A is for organizations that fully outsource cardholder-data handling, while SAQ A-EP applies to e-commerce merchants whose websites influence the payment flow and therefore face more controls. Organizations that store or send plaintext card data typically require the far more extensive SAQ D, whereas physical retailers may use forms such as SAQ B, B-IP, C-VT, C, or P2PE HW depending on their terminals, connectivity, and data-storage practices. Third-party payment processors, tokenization providers, and validated point-to-point encryption solutions can reduce the systems in PCI scope, although merchants remain responsible for selecting the correct assessment and validating service-provider compliance. ROCs examine more than 300 controls and must be performed by certified assessors, while failed assessments require remediation plans and may increase compliance costs; the discussion also notes newer PCI DSS requirements affecting SAQ A, including stronger password rules and authenticated quarterly external vulnerability scans.

Payment data migration involves transferring stored credentials such as credit card numbers, bank account details, tokens, and sometimes PII or KYC information from a payment service provider to an independent vault or another processor, often to improve data ownership, portability, PCI compliance, and negotiating flexibility. The process typically begins by identifying authorized internal contacts, understanding the existing integration and processor requirements, and coordinating securely with both the current provider and receiving platform, which may require PCI Level 1 compliance, an attestation of compliance, service-provider listings, and encryption keys. Exported data commonly arrives in CSV or JSONL files and is transferred through secure methods such as SFTP, HTTPS, or processor-specific channels, with testing on partial or synthetic data recommended before the full migration. Migration timelines and costs vary by processor and project scope, while the intended outcome is generally tokenized payment data that can be securely integrated into business systems, retain links to existing customer identifiers, and reduce dependence on a single payments provider.

Basis Theory describes a rebuild of its checkout SDK, Elements v3, which uses iframe-based fields to collect card data without exposing it to customer servers, similar to offerings from Stripe, VGS, Adyen, and Braintree. The company emphasizes time to interactive—the point at which customers can type into card fields—and P95 latency as measures intended to better reflect user experience than averages, particularly on unreliable connections. In controlled Chrome, sandbox, and simulated-network tests, Basis Theory reports that v3 reduced median interactive time from 736 ms to 135 ms compared with v2, reduced transferred data from 1,138 KB to 86 KB, and improved slow-3G loading from 29.7 seconds to 5.9 seconds. It also reports faster and smaller performance than the competing SDKs tested across unthrottled, 4G, and slow-3G conditions, while noting that real-world results can differ by device, network, and location. Migration from v2 is presented as relatively straightforward because the create, mount, and tokenize workflow remains unchanged, although initialization is now synchronous, some element names have changed, and event payloads are available under event.detail.

Payment orchestration helps merchants manage transactions across multiple payment service providers, fraud tools, billing platforms, geographies, and payment methods, aiming to improve approval rates, reduce fees, and provide redundancy during processor outages. The text distinguishes orchestration, which consists of routing and retry rules, from a payment vault, which securely stores portable payment tokens, and argues that merchants should consider who owns the vault and controls the logic rather than treating both as a single bundled purchase. It contrasts third-party platforms that provide bundled vaulting and prebuilt rules with a vault-first model that allows businesses to retain token ownership, build their own routing configurations, or use outside orchestration partners. An example involving fintech company Felix describes moving tokens from an orchestrator to a separately controlled vault, reportedly reducing payment latency by 50 percent and enabling direct processor integrations. The text also recommends evaluating vendors’ token portability, outage resilience, pricing structure, and flexibility over routing rules, and suggests testing a vault-first implementation through a limited parallel proof of concept before changing existing payment relationships.

As customer support shifts toward chatbots, live chat, and AI voice agents, businesses may inadvertently expand their PCI-DSS compliance scope if these systems access, display, store, or transmit full payment card data or related personally identifiable information. The cardholder data environment encompasses every person, process, and system that handles such information, making the compliance burden and audit requirements more significant as merchants grow through PCI levels. To limit chatbot exposure, organizations can design interfaces so primary account numbers bypass the chat application through embedded iFrames, pass-through workflows, or third-party token vaults that collect and store sensitive data in a PCI Level 1 environment. In these models, chat systems receive only tokens, statuses, or confirmation codes rather than reversible card data, which can reduce compliance costs and help protect customer information.

As businesses expand across regions and payment methods, they may face processor outages, inconsistent local approval rates, and increased compliance demands, leading them to choose between building an in-house token vault or using a third-party provider. Third-party tokenization providers replace sensitive payment data with tokens while securely storing the original data, potentially reducing PCI compliance scope and enabling redundancy across processors, although customers retain responsibility for handling tokens and related systems. Key selection criteria include a straightforward developer experience with clear APIs and testing tools, data portability and processor-agnostic tokens to avoid vendor lock-in, strong security certifications such as PCI Level 1, SOC 2, HIPAA, and ISO 27001 where relevant, scalable and transparent pricing, reliable uptime, and responsive support. Costs generally depend on transaction volume, stored tokens, and optional services, while the ability to migrate data away from a provider is presented as an important consideration. The passage contrasts the potentially six-to-nine-month effort of creating a compliant internal card-data environment with the faster implementation offered by external services, while promoting Basis Theory as an example of a provider offering these capabilities.