[dgaudet]

is there technology around this? i mean i can imagine an API where the CC# itself is only necessary in the first transaction with a new vendor, during which the vendor makes a (signed) request for a vendor-specific token to use for future payments, and can forget the CC# immediately; future payment requests use the same signature chain and the vendor-specific token... making it easy to invalidate any/all of these tokens if the data is compromised, or if the end-user wants to invalidate a specific recurring payment, etc.

i'm in fantasy land, right?

[aeorgnoieang]

This is exactly how Stripe works. Except you don't even need the credit card info at all, even initially – Stripe handles that.

Now that's currently only online, but they're releasing a point of sale product soon too. But even with that, you connect to their card reader and receive a token that you can use.

[evan_]

This is how every payment provider/processor I've ever worked with works, going back more than a decade.

In fact Stripe and Braintree (and I'm sure others) have systems where the implementing service doesn't get the credit card number at all- the payment information is sent directly to the processor from the client and the implementing service only gets a vault token.