But isn't that just between Stripe and the company requesting payment?
e.g: Acme, Inc. sends Stripe your CC#, Stripe sends them some unique token, and they store that; correct?
So Stripe still has your CC#, and is at risk.
So this is really just risk mitigation; what I think TP is suggesting we need is unique authorizations at the banking level.
Something on the order of virtual credit cards, or temporary tokens, which are ultimately verified by your bank [or in other words: the lender(s) making anti-fraud guarantees, etc.]
(e.g: this token is authorized for 24 hours up to this limit; this token is authorized indefinitely up to $xx/mo.; this token is authorized for 1 year; etc.)
No. Customer sends Stripe their CC number, via AJAX in the browser. Acme, Inc. never has it even transiently. Stripe return a token to the browser, which is sent in a POST to Acme, Inc., then they verify it server side with a private API key.
Edit: yes Stripe has your number, but since their sole business is about securing that information, they probably do a better job of it than your typical online merchant.
e.g: Acme, Inc. sends Stripe your CC#, Stripe sends them some unique token, and they store that; correct?
So Stripe still has your CC#, and is at risk.
So this is really just risk mitigation; what I think TP is suggesting we need is unique authorizations at the banking level.
Something on the order of virtual credit cards, or temporary tokens, which are ultimately verified by your bank [or in other words: the lender(s) making anti-fraud guarantees, etc.]
(e.g: this token is authorized for 24 hours up to this limit; this token is authorized indefinitely up to $xx/mo.; this token is authorized for 1 year; etc.)