Sign in
An image of the Stripe logo
Create account
Sign in
Home
Payments
Business operations
Financial services
Developer tools
All products
Home
Payments
Business operations
Home
Payments
Business operations
Financial services
Developer tools
Support
Overview
Overview
Global Issuing
Getting started
Create cards
Cards
Virtual cards
Physical cards
Testing physical cards
Replacement cards
Digital wallets
Support
Controls
Spending controls
Real-time authorizations
Fraud protection
3D Secure
Funding
Balance
Connect
Purchases
Authorizations
Transactions
Disputes
Testing
Merchant categories
Additional information
Marketing guidance (Europe/UK)
Product and marketing compliance guidance (US)
Issuing
·
HomeFinancial servicesIssuing cards

Issuing fraud protection

Learn how Issuing helps 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 (for example, if the authorization method is online or keyed_in).

Was this page helpful?
Questions? Contact us.
View developer tutorials on YouTube.
Check out our product changelog.
Powered by Markdoc
You can unsubscribe at any time. Read our privacy policy.
On this page
Default spending controls
Verification data
Stripe Shell
Test mode
▗▄ ▄▟█ █▀▀ ▗▟████▙▖ ██████ ███▗▟█ ███ ███▗▟██▙▖ ▗▟█████▙▖ ███▖ ▀▀ ███ ███▀▀▀ ███ ███▀ ███ ███ ███ ▝▜████▙▖ ███ ███ ███ ███ ███ █████████ ▄▄ ▝███ ███ ▄ ███ ███ ███▄ ███ ███ ▄▄ ▝▜████▛▘ ▝▜███▛ ███ ███ ███▝▜██▛▘ ▝▜█████▛▘ ███ ▀▘
Welcome to the Stripe Shell! Stripe Shell is a browser-based shell with the Stripe CLI pre-installed. Login to Stripe docs and press Control + Backtick on your keyboard to start managing your Stripe resources in test mode. - View supported commands: - Find webhook events: - Listen for webhook events: - Call Stripe APIs: stripe [api resource] [operation] (e.g. )
The Stripe Shell is best experienced on desktop.
$