Smarter saved cards(stripe.com)
stripe.com
Smarter saved cards
https://stripe.com/blog/smarter-saved-cards
13 comments
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.
[deleted]
So why can't anyone else do this? Having to go through a large number of services to change my card details because I once used it Target was annoying. And then not too much later again because I used the new one at Home Depot was annoying.
(For people outside the US, both Target and later Home Depot got hacked. Many banks proactively replaced their customer cards if they had transactions at those stores, which meant new numbers, expiry and CVC even if no fraud occurred on the card.)
(For people outside the US, both Target and later Home Depot got hacked. Many banks proactively replaced their customer cards if they had transactions at those stores, which meant new numbers, expiry and CVC even if no fraud occurred on the card.)
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?
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?
Well the brute forcing of it would be mighty suspicious: the number on the back has a 1,000 or 10,000 combinations. So that will be noticed, even if you got the first 12 numbers right on the first try. Also, theoretically, of the remaining 12 numbers, 6 should change with each new card, which is another 1,000,000 possibilities (and bigger banks may change more numbers than that)!
The number on the back is generated by an algorithm with secrets that are not very secret (though apparently "secret enough").
Seems like you could just have it not work until a card has been on system for certain amount of time. That way people couldn't just upload card they stole? Would also make easy to detect those who uploaded stolen cards
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.
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.
Check out final http://getfinal.com it seems like what they're working on could potentially solve this problem.
Over a decade ago several places (eg Amex IIRC) would let you generate "aliases" for your card, which worked well. You couldn't limit amounts or expiry like final does. It would be nice if my bank started doing that, as I really don't want yet another financial relationship and sure as hell do not want another pin.
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.
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'm not so sure I like this feature. One of the best parts about getting a new card is having all those things you forgot about that were still charging you $5 a month slip away by getting a fresh number. I think of it as financial spring cleaning. Later, you re-enter the new one for the things you really need.
I realize it costs stripe money to have that happen but from a security standpoint and for purely cleaning up rouge charges every once in a while some people like being able to start over.
I realize it costs stripe money to have that happen but from a security standpoint and for purely cleaning up rouge charges every once in a while some people like being able to start over.
[deleted]
How does this work from a security standpoint? Assuming my card information is stolen and used via a Stripe form, or a merchant I used previously decides to bill me fraudulently, and I change my card details, what prevents them from just getting the new info?
Does whatever mechanism the bank<->Stripe communication uses know not to notify Stripe of the new details if the card is being replaced for fraud rather than natural expiration?
I expect somebody on Stripe's end has thought of this and figured out how to handle it, I just don't know enough about how this kind of information-sharing works to know how they solved it.
Does whatever mechanism the bank<->Stripe communication uses know not to notify Stripe of the new details if the card is being replaced for fraud rather than natural expiration?
I expect somebody on Stripe's end has thought of this and figured out how to handle it, I just don't know enough about how this kind of information-sharing works to know how they solved it.
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.
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.
This is pretty huge. Anyone who bills on a regular basis will know how frustrating it can be chasing customers whose credit cards have expired.
Having the cards automatically update is a game changer.
Having the cards automatically update is a game changer.
This is awesome. I just had a message from Google the other day about an expiring card that they "automatically" updated, and was wondering how they did that!
Can the next thing on the list be a way to present Stripe Checkout with a customer ID, and have Stripe handle the rest (ie. cards stored, which card to use, updating expired cards)?
Currently, the "remember me" function causes extra friction and doesn't allow for services that already have the customers phone number registered - and Checkout is meant to be straight forward.
Appreciate this isn't a feature request thread, but as you're looking to make the process simpler for end users, helping sites handle repeat customers in a clean, simple way seems like a big win!
Can the next thing on the list be a way to present Stripe Checkout with a customer ID, and have Stripe handle the rest (ie. cards stored, which card to use, updating expired cards)?
Currently, the "remember me" function causes extra friction and doesn't allow for services that already have the customers phone number registered - and Checkout is meant to be straight forward.
Appreciate this isn't a feature request thread, but as you're looking to make the process simpler for end users, helping sites handle repeat customers in a clean, simple way seems like a big win!
Hi Daz,
We're working on something related to your request over at AccountDock (https://accountdock.com). Email me at [email protected]
I'd love to chat with you to get a better understanding of your needs and how we might be able to help :)
Sure - sounds interesting!
The business can watch for this "customer.card.updated" event, but am I understanding correctly that it doesn't actually need to do so, and next month's payment will complete without any action on the part of the business?
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.
This is awesome and should help reduce friction for SaaS business AND customers.
Is this feature pretty unique to Stripe or do competitors also have it?
Is this feature pretty unique to Stripe or do competitors also have it?
This is an amazing feature. I just had to go through half a dozen websites and update my company credit card details for this exact reason. Each and every time I do that, I get to evaluate whether or not I actually need the product or not - possibly leading to cancellation. This way retention is kept with no effort on the business or customer side.
It will be interesting to see how many people are unhappily surprised with the automatic renewal.
This is awesome as a saas owner, but maybe more so as a consumer. I HATE updating my credit card after getting a new number or new expiration date. It's seriously a major pain and I hope everyone I pay ends up using stripe by 2016.
Wow, this is awesome. It's a shame that quite a few startups will be put out of business by this though, eg. https://expiry.io/
Braintree's version, FYI
https://www.braintreepayments.com/blog/account-updater
When your credit card expires, the CVC code is re-generated and changes. I assume that does not matter for Stripe, as CVC is only checked at the initial tokenization not re-charges.
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.
How can I make sure that an online shop will not be able to draw money off my card after the expiry date? If I understood the technical magic here, that would help.