April 2026 Summaries

Linque, a payment method discovery product from Basis Theory, is designed to reduce checkout friction by allowing customers to find and select existing Visa, Mastercard, or American Express cards with a phone number, SMS verification, and CVV rather than manually entering card details. It offers an inline wallet flow that replaces standard card-entry forms and an asynchronous pre-load option for merchants with verified customer phone numbers, while providing merchants with billing information and either a raw primary account number or processor token. Unlike accelerated checkout services such as Shop Pay, Stripe Link, and PayPal FastLane, which operate through proprietary ecosystems, Linque is presented as processor-agnostic and compatible with merchants’ existing payment vaults and processor relationships. The product targets e-commerce retailers, subscription businesses, and payment platforms seeking to improve conversion, payment continuity, and card-failure prevention while retaining control over customer payment data. Basis Theory states that Linque can identify eligible payment methods for approximately 80% of U.S. consumers and emphasizes its focus on data portability, merchant ownership, and avoiding third-party network lock-in.

Basis Theory has rebuilt its Portal on a modern Next.js foundation with a refreshed interface, top navigation, faster performance, and unchanged core functionality, creating a more consistent experience across its products while supporting future onboarding and observability improvements. Test tenants now operate on infrastructure isolated from production, requiring test API calls to use api.test.basistheory.com, updated allowlists where applicable, and v1-test webhook signature verification, while newer SDKs can simplify configuration through a test-environment parameter. The Elements v3 beta introduces a unified card input component, substantially faster interactivity, fewer network requests, smaller transfer sizes, and centralized design tokens that apply theming and dark-mode support across components. 3DS authentication sessions can now include custom backend metadata that is returned through later webhooks to improve transaction correlation, and the Python SDK’s transport-level retry logic has been corrected to handle transient network failures more reliably.

Visa’s Digital Commerce Authentication Program (DCAP) lets merchants supply validated signals such as device identifiers, email, billing address, and IP address before authorization, giving issuers more context to approve legitimate purchases, reduce fraud, and limit false declines without adding customer challenges or creating a new authentication flow. The program can offer eligible credit customer-initiated transactions a net five-basis-point interchange savings, potentially rising to ten basis points when combined with network token incentives, while its performance benefits may also extend to debit and merchant-initiated transactions. Merchants can participate through data-only 3D Secure, Visa token services, or the more flexible IDX direct API, which supports both PAN and token transactions. Although the concept requires only a few data elements, implementation can be difficult because customer, device, credential, and authorization data are often fragmented across front-end systems, processors, and platforms. Basis Theory positions its infrastructure as a way to collect, standardize, store, and inject this data across the available integration paths, allowing merchants to retain existing processor relationships while preparing for a broader shift toward identity-rich, context-driven payment decisions.

Enterprise retailers commonly use multiple payment service providers, but bundled services can create duplicated costs and fragmented control over features such as Account Updater, network tokens, 3D Secure authentication, and BIN data. The text argues that centralizing these capabilities at a payment vault level allows merchants to provision them once under their own ownership, rather than separately through each processor. This approach can give merchants greater control over which cards receive account updates, retain portability of network tokens through a merchant-owned Token Requestor ID, unify 3DS data and authentication tuning across processors, and provide a standardized, enriched BIN-data source for routing, fraud prevention, compliance, and surcharging. By consolidating these functions, merchants may reduce fees, lessen engineering overhead, improve visibility, and avoid dependence on individual PSPs when changing or expanding their payment stack.

Cannabis, CBD, and hemp merchants face elevated payment-processing risks because processors may terminate accounts, delay disbursements, or impose strict compliance requirements, making operational redundancy important. The material recommends using multiple payment service providers and independently tokenizing payment data so customer credentials, recurring billing, and transaction routing can be moved without relying on a single processor’s vault. Cannabis dispensaries commonly use cashless ATM transactions, in which debit withdrawals are routed to the merchant rather than provided as cash, although these arrangements can require merchants to keep change available. Card-network classifications and restrictions vary: cannabis businesses are often treated as high-risk and may fall under Visa’s Tier 1 MCC 5912, while Mastercard uses broader existing categories, and hemp-derived CBD businesses generally face fewer but still substantial restrictions. The 2018 Farm Bill legalized hemp containing less than 0.3% THC, but CBD processing remains a specialized, compliance-focused market. Recommended practices include understanding network and state regulations, maintaining multiple experienced processing partners, clearly communicating business and payment terms, quickly resolving disputes and chargebacks, and preserving PCI DSS compliance while retaining portability of payment data.

Credit card tokenization replaces sensitive card data such as primary account numbers with unique tokens that cannot be reversed, allowing businesses to process and use payment information while reducing exposure to raw cardholder data and PCI DSS compliance scope. The guide describes how third-party, processor-independent vaults can capture and securely store card data through web iFrames, mobile SDKs, and call-center integrations, keeping sensitive information out of internal systems. It contrasts processor-native tokens, which generally cannot be used outside a single payment provider’s ecosystem, with independent vaults that are intended to support portability across processors, fraud tools, partners, and analytics workflows. It also argues that centralized token vaults can help organizations route payments among providers, securely receive or share card data, conduct deduplication and analysis, and reduce the operational burden of maintaining a PCI-compliant cardholder data environment, particularly as PCI DSS requirements expand.

Basis Theory has rebuilt its Elements SDK, which lets developers collect payment details, bank information, and personally identifiable information through secure iframes without sensitive data entering their own systems, helping limit PCI compliance scope. The previous version had accumulated technical debt, including oversized bundles, numerous network and iframe requests, difficult maintenance, and repetitive per-field styling that could slow checkout experiences and complicate integrations. Elements v3 reduces time to interactive from 803 milliseconds to 402 milliseconds, cuts network requests from 52 to 8, lowers transfer size from 3,473 KB to 239 KB, and eliminates 44 iframe sub-requests. It also introduces a design-token styling system for shared colors, typography, spacing, borders, shadows, dark mode, and runtime theme controls, while retaining per-element customization. The redesigned architecture aims to simplify maintenance, accelerate feature development, support AI-assisted engineering workflows, and provide a smoother upgrade path for existing Elements v2 customers.

A payments forward API enables merchants to send transactions to multiple payment service providers or gateways without handling customer payment data in plain text, potentially reducing PCI-DSS scope while improving authorization rates and processing costs. When paired with tokenization and an independent programmable payments vault, it can support multi-processor routing based on factors such as geography, payment method availability, risk specialization, likelihood of approval, and provider fees. Forward APIs supplied by individual full-service PSPs may limit this flexibility because those providers have incentives to retain transaction volume within their own platforms. Successful adoption requires advance planning for diverse payment endpoints, regular reviews of provider relationships, continued PCI compliance for systems that remain in scope, and scalable routing architecture. Decisioning engines, potentially using AI, can further optimize processor selection, add security controls, and support services such as currency conversion, but the effectiveness of the approach depends heavily on thoughtful partner selection, compliance planning, and system design.

Network Transaction IDs (NTIDs) are card-network-assigned authorization references that link later merchant-initiated transactions, such as recurring or card-on-file charges, to the original cardholder-initiated transaction where consent and authentication occurred. Visa and Mastercard require many merchant-initiated transactions to include the original NTID, and missing or invalid references can lead to issuer declines or force merchants to request card details and CVC again. The passage argues that NTIDs are often retained by the payment service provider that processed the initial transaction, creating difficulties for merchants using multiple providers or migrating processors because the consent history may not transfer with payment tokens. It recommends that merchants retain NTIDs alongside card tokens in a merchant-controlled vault so they can route transactions across providers, preserve stored-credential histories during migrations, and reduce dependence on a single payment processor.

A Bank Identification Number, or BIN, is the first four to eight digits of a payment card and identifies the card issuer, bank, card network, and certain transaction attributes, helping payment networks route authorization requests. Also called an Issuer Identification Number, it includes a Major Industry Identifier and network-specific number ranges, such as Visa cards beginning with 4 and Mastercard cards within designated ranges. As issuers move from six-digit to eight-digit BINs to expand available identifiers, card-number length remains unchanged, though PCI standards generally limit displayed information to the first six and last four digits. BIN fraud can involve criminals combining known BIN prefixes with randomly generated digits to test for valid cards, often indicated by unusual volumes of small transactions, rapid declines, or abnormal transaction activity. Organizations can reduce exposure to card data by using tokenization, which substitutes sensitive payment information with secure tokens while preserving limited data needed for business operations.