10 ms·

This is great news. While working with Stripe today, I noticed something a bit unnerving. The Stripe charge method will create a charge even if the CVC and th

by drm237 14y ago

This is great news. While working with Stripe today, I noticed something a bit unnerving. The Stripe charge method will create a charge even if the CVC and the AVS fraud checks fail. It's then up to you to monitor this and reverse the charge if you feel it's too high risk (there's no fee reversal though). There are ways to get around this with custom development, but that doesn't help for people who are using software that's already integrated with Stripe. It would be great to see a fraud setting that would allow you to prohibit charges from going through depending on what checks fail.

purephase 14y ago
This and the mass pay option in Paypal is what keeping us from migrating. I was/am? still working on a better fraud model for Paypal that could easily be swapped out for Stripe given the similarities between the payment provider responses. Not that I'm promoting Paypal's fraud controls in any way. They're terrible as well. The way I see it now, Stripe made it easy. If they could lock down the secure aspect they'll run away with the game. Integrating with something like maxmind might be a good direction for them to look. Edit: Just noticed the Stripe Apps functionality. It might suffice for an alternative to the mass pay functionality that Paypal provides. This just got a little more interesting.
- adambenayoun 14y ago
  Check out a blog post we wrote some time ago about fraud prevention (we're both using paypal and stripe). http://www.binpress.com/blog/2012/07/31/fighting-online-fraud-pitfalls-and-solutions/ http://www.binpress.com/blog/2012/07/31/fighting-online-frau... Might be of interest to you.
michaelschade 14y ago
As a brief bit of background: these charges are accepted because card brands do not always decline if the CVC fails (and AVS has no effect); instead, they're taking several signals into account. We expose as much data as possible to give you full control (https://answers.stripe.com/questions/what-controls-for-fraud-prevention-does-stripe-offer https://answers.stripe.com/questions/what-controls-for-fraud...). That said, I really appreciate the feedback. We're actively working on better fraud controls that should be ready soon!
- drm237 14y ago
  Thanks for the response. I use Stripe for 3 companies and absolutely love it! While giving us full control is nice, it doesn't help when we're using a pre-built integration, like an ecommerce platform that supports Stripe. In this case, we either need to re-write the Stripe integration or accept that we have no automatic fraud controls.
  - subpixel 14y ago
    Agreed. I have a client reeling from fraudulent orders right now and looking to change payment systems. In order to suggest Stripe I'd need to show how he can set up his own rules within Stripe, e.g.: - billing country/shipping country mis-match? DENY - AVS mismatch or missing? REVIEW - CVC mismatch or missing? DENY - order over $X? REVIEW - order from country in list X? DENY Those are just the settings this client would prefer, but each user should be able to roll their own, regardless of whether they're using a custom integration or off-the-shelf third-party integration.
- purephase 14y ago
  This is great news. I can't wait to hear about them.
someone13 14y ago
So, if you create a customer, Stripe will check the CVC and AVS and return the results of those checks (Ctrl-F for "CVC and Address Verification Responses" on https://stripe.com/docs/api https://stripe.com/docs/api). From there, you can make a decision whether or not to create a charge for that customer. Edit: To clarify a bit (and because I've got a couple minutes of free time), here's more details: 1. Create a customer, giving the "card" parameter with the CVC, address_line_1, and address_zip included. This can be done with Stripe.js, or whatever. 2. The returned data from the "create customer" api method will contain a "active_card" dict, with details as shown in the "Creating a new charge" section in their API docs. 3. Given this active_card dict, check the active_card. cvc_check, active_card.address_line1_check and active_card.address_zip_check values. From this, make a decision on whether to charge the customer. 4. If you've decided to make the charge, then create a new charge with this customer.
- drm237 14y ago
  Thanks for the response and follow up details. I do realize that this is possible with Stripe, but when using software that already integrates with Stripe, doing additional custom integration is less than ideal. I would also argue that it violates the principle of least astonishment to have a charge go through when the supplied data is inaccurate. I'm a huge fan of Stripe and find the API incredibly well designed which is why I was so surprised when I came across this today. It's certainly not causing me to migrate away from Stripe, it just means that I'll have to manually keep an eye on things for now.
  - boucher 14y ago
    It's worth noting that people often typo things like billing address or cvc code, and that the majority of these failures are not in fact fraud. At that point, it's also a usability question about what the best behavior really is. The banks do take CVC into account when deciding whether or not to approve the charge, and obviously also run their own (often aggressive) fraud prevention algorithms to deny suspicious charges. All that being said, we're working on some tools to make this a bit easier.

by drm237 14y ago

purephase 14y ago

This and the mass pay option in Paypal is what keeping us from migrating. I was/am? still working on a better fraud model for Paypal that could easily be swapped out for Stripe given the similarities between the payment provider responses. Not that I'm promoting Paypal's fraud controls in any way. They're terrible as well. The way I see it now, Stripe made it easy. If they could lock down the secure aspect they'll run away with the game. Integrating with something like maxmind might be a good direction for them to look. Edit: Just noticed the Stripe Apps functionality. It might suffice for an alternative to the mass pay functionality that Paypal provides. This just got a little more interesting.

adambenayoun 14y ago
Check out a blog post we wrote some time ago about fraud prevention (we're both using paypal and stripe). http://www.binpress.com/blog/2012/07/31/fighting-online-fraud-pitfalls-and-solutions/ http://www.binpress.com/blog/2012/07/31/fighting-online-frau... Might be of interest to you.

michaelschade 14y ago

As a brief bit of background: these charges are accepted because card brands do not always decline if the CVC fails (and AVS has no effect); instead, they're taking several signals into account. We expose as much data as possible to give you full control (https://answers.stripe.com/questions/what-controls-for-fraud-prevention-does-stripe-offer https://answers.stripe.com/questions/what-controls-for-fraud...). That said, I really appreciate the feedback. We're actively working on better fraud controls that should be ready soon!

drm237 14y ago
Thanks for the response. I use Stripe for 3 companies and absolutely love it! While giving us full control is nice, it doesn't help when we're using a pre-built integration, like an ecommerce platform that supports Stripe. In this case, we either need to re-write the Stripe integration or accept that we have no automatic fraud controls.
- subpixel 14y ago
  Agreed. I have a client reeling from fraudulent orders right now and looking to change payment systems. In order to suggest Stripe I'd need to show how he can set up his own rules within Stripe, e.g.: - billing country/shipping country mis-match? DENY - AVS mismatch or missing? REVIEW - CVC mismatch or missing? DENY - order over $X? REVIEW - order from country in list X? DENY Those are just the settings this client would prefer, but each user should be able to roll their own, regardless of whether they're using a custom integration or off-the-shelf third-party integration.
purephase 14y ago
This is great news. I can't wait to hear about them.

someone13 14y ago

So, if you create a customer, Stripe will check the CVC and AVS and return the results of those checks (Ctrl-F for "CVC and Address Verification Responses" on https://stripe.com/docs/api https://stripe.com/docs/api). From there, you can make a decision whether or not to create a charge for that customer. Edit: To clarify a bit (and because I've got a couple minutes of free time), here's more details: 1. Create a customer, giving the "card" parameter with the CVC, address_line_1, and address_zip included. This can be done with Stripe.js, or whatever. 2. The returned data from the "create customer" api method will contain a "active_card" dict, with details as shown in the "Creating a new charge" section in their API docs. 3. Given this active_card dict, check the active_card. cvc_check, active_card.address_line1_check and active_card.address_zip_check values. From this, make a decision on whether to charge the customer. 4. If you've decided to make the charge, then create a new charge with this customer.

drm237 14y ago
Thanks for the response and follow up details. I do realize that this is possible with Stripe, but when using software that already integrates with Stripe, doing additional custom integration is less than ideal. I would also argue that it violates the principle of least astonishment to have a charge go through when the supplied data is inaccurate. I'm a huge fan of Stripe and find the API incredibly well designed which is why I was so surprised when I came across this today. It's certainly not causing me to migrate away from Stripe, it just means that I'll have to manually keep an eye on things for now.
- boucher 14y ago
  It's worth noting that people often typo things like billing address or cvc code, and that the majority of these failures are not in fact fraud. At that point, it's also a usability question about what the best behavior really is. The banks do take CVC into account when deciding whether or not to approve the charge, and obviously also run their own (often aggressive) fraud prevention algorithms to deny suspicious charges. All that being said, we're working on some tools to make this a bit easier.