Interested in exactly when it becomes impractical. Personally I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for.

Honestly shocked by how much pushback I've had on this on this thread. I feel like I made a fairly innocuous comment that, essentially, was just suggesting that it's probably best practice to avoid storing customer card details in your own database. That seems to me about as uncontroversial as saying 'you should not be storing plaintext passwords', but apparently, judging from the replies I've seen, it's hopelessly naive, and you can't actually handle payments without storing CC numbers.

Which comes as a bit of a surprise to me, as in my day job I work on an e-commerce system that handles a billion dollars of credit card transactions a year, including stored payment methods and processing recurring billing - and we haven't got a single credit card number in any of our databases. So I kind of suspect it can be done.

> Interested in exactly when it becomes impractical

A couple examples where the Stripe model and scale of tokenization breaks down today:

- You're an airline and you need to have a digital wallet that stores payment details so you can buy your ticket on web, upgrade your seat on mobile, and buy a drink in-flight using the flight attendant's POS device

- You sell a product at high-risk of chargebacks that is not permitted by the major tokenization providers' terms-of-service (there are some surprises here that rule out several Fortune 100 use cases!)

- You're a $10B+ retailer where the difference between a 2.9% payment processing cost and a 1.6% payment processing cost pays for an entire team of people to focus on minimize processing costs by routing different payments to different gateways depending on fees (eg American Express goes one place, Visa goes another)

Now: if you are a mom-and-pop scale DTC shop selling only via web, you should probably be taking advantage of tokenization instead of storing credit card data yourself!

The PCI-DSS council does give guidance on how you handle credit card information securely when you cannot use a tokenization approach, and a lot of it boils down to what we'd consider foundational software engineering practices. (Don't let engineers have access to production data! Rotate your credentials periodically! Log events and maintain those logs so they can be audited!) It does increase your costs, complexity, and talent needs but it's also not an antipattern and there is relatively straightforward guidance on how to do so securely.

> Interested in exactly when it becomes impractical.

Having multiple payment service providers, for example (or the plan to do so in the near future).

Another example would be complex legacy systems (especially in the travel segment, constellations between various service providers get complex quickly).

> I'm prepared to go to quite an extraordinary amount of effort to make sure PANs and cardholder data never comes near any system I am responsible for.

No objections there :)

> you can't actually handle payments without storing CC numbers.

Now you're putting up a straw man. It's definitely not impossible, but in some circumstances, it can be very hard.

Also, somebody will have to store the PANs in a database in the end, even if it's just the payment service providers themselves. There are much less payment service providers than merchants out there, but by the same logic, that makes them a much more valuable goal for attackers.