Create account
Sign in
Home
Payments
Business operations
Financial services
Developer tools
Security
All products
Home
Payments
Business operations
Home
Payments
Business operations
Financial services
Developer tools
Support
Overview
Overview
Getting started
Creating cards
Cards
Virtual cards
Physical cards
Digital wallets
Controls
Spending controls
Real-time authorizations
Fraud protection
Funding
Balance
Connect
Purchases
Authorizations
Transactions
Disputes
Testing
Merchant categories
Business financing
issuing
ยท
HomeFinancial servicesCard creation

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, "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.

If spending_limits are not set, a default spending limit will be applied to the newly created card in the amount of 500 USD per day. To disable this behavior, please reach out to support.

Verification data

Card-not-present

Card-not-present (CNP) transactions include e-commerce purchases, recurring subscriptions, and phone orders. CNP transactions are a frequent target for fraud.

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

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.

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

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?
Questions? Contact us.
Developer tutorials on YouTube.
You can unsubscribe at any time. Read our privacy policy.
On this page
Default spending controls
Verification data