Fraud protection

    Learn how we help protect you against fraud.

    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, "authorized_amount": 199, "authorized_currency": "usd", "created": 1574104953, "currency": "usd", "held_amount": 199, "held_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" } },

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

    Was this page helpful?

    Feedback about this page?

    Thank you for helping improve Stripe's documentation. If you need help or have any questions, please consider contacting support.

    On this page