Hacker News Reader

Comment by drm237 | Hacker News Reader

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.

View on HN

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). 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.

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.

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.

Thanks Ross. I can certainly understand an address typo, but a CVC typo seems like a valid reason for denying a transaction. Glad to hear that you're aware and are working on tools to help us!

Your complaint is with the third party providers. Stripe's charge method does what it says on the tin: it charges the card. If your third party integration software doesn't expose a method to create and validate the customer data (which the Stripe API supports) prior to making the charge, ask them to fully support Stripe's API or provide you with a configurable option for what to do when the CVC/AVS checks fail.

That's certainly one way to look at it. In my opinion, Stripe should be the entity responsible for fraud management and not left up to the individual implementations, but I can certainly see your point of view as well.

The alternative is that you could end up with customers who constantly hit false positives in the fraud detection, and it becomes impossible to charge that person unless Stripe implements a way to "force charge" someone, and then you have to hope your 3rd party Stripe integration also supports and exposes that to you...

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...).

That said, I really appreciate the feedback. We're actively working on better fraud controls that should be ready soon!

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.

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.

This is great news. I can't wait to hear about them.

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.

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-frau...

Might be of interest to you.

Reply on news.ycombinator.com