Charges seem to be failing based on where the card token was created

[Peter Sinnott]

Hi,

I have a website where users can enter card details. The details are tokenised using stripe.js and are passed to the server.

Server side a customer is created , card added and then the card charged. 

For the last day the charges are being declined but only for website users at one location. 

Everything works fine for users at location B. Cards that work at location B fail at location A. Cards that fail at location A work at location B.

Since the charges are done server side and the tokens seem valid (since they can be added as cards) I'm a little confused.

Any ideas?

Thanks,

Peter

[Scott Fotheringham]

I've seen this before and while I never found a concrete answer, it seemed to be that certain locations are listed as high-risk for card fraud by bank security algorithms. We found it was certain IP ranges causing the customer to require manual authentication with their banks.

[Peter Sinnott]

Was this with Stripe or a different service provider? 

Trying to get them to use a different browser atm in case that helps. Using a different IP address might be beyond them.

Thanks,

Peter

On 3 September 2015 at 14:04, Scott Fotheringham <diesel...@gmail.com> wrote:

I've seen this before and while I never found a concrete answer, it seemed to be that certain locations are listed as high-risk for card fraud by bank security algorithms. We found it was certain IP ranges causing the customer to require manual authentication with their banks.

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at http://groups.google.com/a/lists.stripe.com/group/api-discuss/.

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Scott Fotheringham]

No this was with Stripe. I wonder also if this is caused by servers patching last year's POODLE attack - disabling SSL3 fallback - so perhaps old browsers? Post back if different browsers help, I'd be interested to know.

Sorry I can't be more help, like I say I never solved this fully myself!

Maybe a Stripe team member has any ideas?

[Peter Sinnott]

It looks like the issue is to do with automated fraud detection Stripe perform. It was getting upset since we were processing Irish credit cards in Northern Ireland. Kinda a pain.

[Matthew Arkin]

There are a number of things that can cause a variety of card failures and declines. There are also three types of card declines:

1.  Declines that Stripe receive from upstream (aka the customer's bank) - these happen for a bajillion reasons. 

2.  Approved charges ones that Stripe declines because an AVS check failed and you had the appropriate flags set in your account settings

3.  Approved charges that Stripe's machine learning and fraud prevention tools deam as risky / fraudulent. In these cases Stripe will decline the charges with a failure reason of "fraudulent".  

With #1, there is nothing Stripe can do about that and having the customer call the bank is required.

With #2, you could disable the check in the dashboard, have the customer re-enter their zip code, or have them call their bank to add / modify the AVS address. 

With #3, you can mark the transaction as safe via the api or dashboard and then retry the transaction, but this isn't something you should do for all transactions that get flagged as fraudulent unless you trust your fraud detection system more than Stripe's.

As for charges failing based on where the token was created, this can happen is stripe is seeing a lot of token requests for multiple cards happening from one location as it can be a sign of a scammer / bot attempting to see which credit cards are valid.

Hopefully this provides some insights for others who find this thread. 

Matt