January 2023 Summaries

Card-on-file transactions allow merchants to securely store a customer’s payment card details, often through encrypted systems or tokens managed by payment service providers, so future payments or refunds can be completed without re-entering information. They include consumer-initiated transactions, where a customer provides payment details and authorization, and merchant-initiated transactions, which use prior customer consent for recurring, installment, delayed, no-show, reauthorization, or retry payments. Common applications include subscriptions, memberships, repeat orders, installment plans, reservation fees, and add-on purchases, offering faster checkout, improved conversion, more predictable revenue, and reduced administrative effort. However, businesses must account for PCI DSS compliance requirements, card-network processing fees, failed payments caused by expired or replaced cards, and limits imposed by payment-provider-specific tokens. Independent tokenization providers can help businesses retain secure card data control and route payments across multiple providers while reducing the need to operate their own PCI-compliant cardholder data environment.

Organizations deciding whether to build or outsource a cardholder data environment (CDE) must weigh PCI DSS compliance obligations, data flexibility, cost, time to launch, security management, and developer experience. PCI DSS includes more than 300 controls for protecting cardholder data, while scope determines which people, processes, and systems must meet those requirements and attestation validates compliance through questionnaires or formal audits. Card issuers, payment service providers, and tokenization platforms can offload much of the compliance burden, provide ready-made infrastructure, accelerate deployment, and reduce costs, although conventional payment-provider tokens can limit data portability and third-party sharing. Tokenization providers offer greater control and portability without the full complexity of operating an in-house CDE, whereas building internally offers complete ownership of the data environment but can require four to nine months and roughly $145,000 to $500,000 or more to implement, assess, and maintain. Businesses are encouraged to map how card data moves through their systems, identify operational and strategic needs, prioritize objectives and expected returns, seek advice from experienced peers, and test a narrowly scoped proof of concept before selecting an approach.

Building an in-house cardholder data environment (CDE) offers direct control over payment data, processor routing, integrations, latency, and vendor dependence, but requires substantial investment in PCI DSS compliance, security operations, and ongoing maintenance. Organizations that store cardholder data themselves must implement and assess all relevant infrastructure, policies, training, access controls, network protections, scans, penetration tests, and documentation, with initial setup commonly estimated at $125,000 to $300,000 and three to seven months. Compliance requirements can include the extensive SAQ D, regular security testing, or formal audits by Qualified or Internal Security Assessors for organizations processing more than six million annual transactions. Maintaining compliance is a continuous responsibility, particularly as security threats and PCI standards evolve, including the additional controls introduced in PCI DSS v4.0. Tokenization and developer-oriented platforms can reduce exposure and help enforce compliant practices, while many benefits of owning card data may also be available through specialized service providers. As a result, companies most likely to build their own CDE are large retailers and payment service providers with high transaction volumes or specialized operational needs, whereas others may find third-party solutions more economical and faster to deploy.

The update introduces redesigned documentation hosted on Docusaurus, with a streamlined structure aligned to the data lifecycle and expanded getting-started materials, guides, and end-to-end Blueprints, while inviting community feedback and code contributions. Mobile SDK enhancements add payload transformation capabilities, customizable PAN masking and CVV behavior, validation options including Luhn and future-date checks plus custom regex validators, and a createToken service for single-token and strongly typed use cases. The Android SDK now preserves custom-component input state during events such as screen rotation or focus changes, and other improvements include a fix for portal users without metadata and support for custom fonts.

PCI DSS v4 introduces a customized approach that lets eligible organizations replace prescribed defined controls with alternative controls that meet the same security objective, unlike compensating controls, which supplement an unsuccessfully implemented required control. This flexibility can support tailored architectures and newer technologies, such as passwordless multi-factor authentication in place of password-specific measures, but it is intended for organizations with mature risk-based security programs rather than as an easier compliance route. Each customized control requires documented risk analysis, executive approval, a controls matrix, ongoing effectiveness monitoring, and independent assessment by a Qualified Security Assessor (QSA). Because customized approaches are available only to organizations completing a QSA-led Report on Compliance rather than a Self-Assessment Questionnaire, they can increase audit time, cost, and operational overhead. Organizations should therefore consider them when the security, operational, or technological benefits clearly justify the extra expertise, documentation, implementation, and maintenance required.