Fraud protection

Stripe monitors for fraudulent authorizations and automatically blocks any that look suspicious. If we decline the authorization attempt as a result of our fraud analysis, the request_history.reason field on the Authorization is set to suspected_fraud.

"request_history": [
  {
    "approved": false,
    "amount": 2000,
    "created": 1574104953,
    "currency": "usd",
    "merchant_amount": 2000,
    "merchant_currency": "usd",
    "reason": "suspected_fraud"
  }
],
"request_history": [
  {
    "approved": false,
    "amount": 2000,
    "created": 1574104953,
    "currency": "usd",
    "merchant_amount": 2000,
    "merchant_currency": "usd",
    "reason": "suspected_fraud"
  }
],

Default spending controls

Stripe recommends that you implement a combination of spending limits and merchant category controls on your cards and cardholders to help limit your exposure in case fraud is attempted.

Verification data

For e-commerce (card-not-present) authorizations, check the verification_data field on the Authorization object.

"verification_data": {
  "address_line1_check": "not_provided",
  "address_postal_code_check": "match",
  "cvc_check": "match",
  "three_d_secure": {
    "result": "authenticated"
  }
},
"verification_data": {
  "address_line1_check": "not_provided",
  "address_postal_code_check": "match",
  "cvc_check": "match",
  "three_d_secure": {
    "result": "authenticated"
  }
},

The values for address verification (AVS) and CVC checks are one of match, mismatch, or not_provided. While a mismatch is usually a good reason to decline an authorization request, additional verification data may not always be provided (including for legitimate transactions). As a result not_provided on its own is not automatically a reason to decline a transaction.

You can use the authorization_method field to determine the importance of verification_data for your decision (e.g., if the authorization method is online or keyed_in).