Smarter saved cards

What bank does that?

Since Stripe is relying on the banks to give them the updated information surely the banks wouldn't be updating generated card numbers as they would all be unique.

Does this mean that those who hacked Target could have just added the card details to their own Stripe account and waited for Stripe to update the data once the banks got around to replacing the customer cards?

At least with my banks, when they send me updated cards, only a handful of the digits actually change and most of those changes have tended to be in the last 4 digits — which Stripe lets you see, along with the updated expiry month/year.

At this point, it's just a matter of brute forcing the remaining permutations. Am I misunderstanding something or are there countermeasures to protect against such attacks?

Check out final http://getfinal.com it seems like what they're working on could potentially solve this problem.

I have changed my credit card because of a security lapse and found that some recurring charges continued to work against the old card number without me having to update the card at the vendor. I figured that the processor or issuer was handling this for my convenience, based on their knowledge of my established relationship with the vendor.

However I have never had a vendor try to rebill an expired card, even though the CVC's and the expiration year are the only data which changed.

https://spreedly.com offers this card updating as well. You store your customers' payment info with them instead of with a specific processor, and you can charge those cards with Stripe today or PayPal tomorrow just by changing one token in your code.

Google already does this. My wife recently got a new card after hers was mangled by an overzealous cashier. She went to update the information everywhere she knew it belonged, and noticed that her Google Checkout details already had the new card information.

We spent a couple of puzzled hours wondering how in the world Google could have possibly gotten that information before concluding that it must have been a service made available to them by the issuing bank -- Navy Federal in our case -- but not having any real way to confirm it.

We'd scoured the paperwork that we did have and found nothing indicating those terms anywhere, and shockingly, this is our first indication that such a service exists.

Note, I did not call the bank.

I think your may questions may be best answered by better explaining the role of stripe and where the layers of processing are here.

Stripe handles the entirety of the card processing infrastructure, the website (user of their API) can only talk about cards in an abstract sense, they can't get details from it. So businesses using stripe can't leak those sort of card details because they never had them (although a form of java-script "skimming" of the card details might be possible, like skimming an ATM).

If a business using stripe is accused of fraud (because improper charges show up on a customer's card) then stripe removes/limits the API access from that business (until they fix their infrastructure, business practices, or pony up the money, etc). This has nothing to do with having your card details stolen, this is them lying to you and stripe (and they can be sued; unless it was criminal/hacking). This is Stripe's API being misused.

If your card details have been stolen you merely change the card's details. They have only stolen the information required to impersonate you (this is, of course, because cards are poorly designed: they are non-active and don't do any sort of active cryptography, no way to verify physical ownership). Because Stripe has relations with these processors and banks they can be trusted with (limited) access to the information behind the card. Think of the card as a time limited API token. Just because the token was stolen doesn't mean all the actions taken by that user token were fraudulent, and if properly setup, those actions can continue. Of course the user must still be vigilant with fraudulent actions taken on behalf of the card (but at this point they are easier to notice, and the bank will be more vigilant), and those relationships Stripe has will allow it to cancel, pause, or verify any transactions that may have been initiated during the period after the card was stolen.

Chargebacks prevents merchants from using this fraudulently. Risk is always on the merchant when card isn't present.

Hi Daz, We're working on something related to your request over at AccountDock (https://accountdock.com). Email me at oliver@accountdock.com I'd love to chat with you to get a better understanding of your needs and how we might be able to help :)

That's right. We only fire the webhook in case you want to, say, update the expiry or last four digits you're rendering to your user.

It will be interesting to see how many people are unhappily surprised with the automatic renewal.

Yup, after you tokenize the card CVC (CVV2, CID, etc) is no longer needed. So even though it will change it won't affect the validity of the card since this sounds like a deal with the networks. Also, you're not allowed to store CVC any way so the system has to work without it. In some cases where fraud is suspected some processors can / may ask you to provide your current CVC before letting the charge go through.