Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Developer tools
Get started
Payments
Finance automation
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Overview
Start an integration
Products
Global Payouts
Capital
Issuing cards
    Overview
    How Issuing works
    Global availability
    Manage fraud
    Cards
    Choose your card type
    Virtual cards
    Issue virtual cards
    Physical cards
    Manage cards
    Digital wallets
    Replacement cards
    Card programs
    Program management
    Customize your card program
    Add funds to your card program
    Credit Consumer Issuing
    Controls
    Spending controls
    Advanced fraud tools
    3DS
    Fraud challenges
    Real-time authorizations
    PIN management
    Issuing Elements
    Token Management
    Funding
    Balance
    Postfund your integration with Stripe
    Postfund your integration with Dynamic Reserves
    Purchases
    Authorizations
    Transactions
    Disputes
    Testing
    Merchant categories
    ATM Usage
    Issuing with Connect
    Set up an Issuing and Connect integration
    Update terms of service acceptance
    Connect funding
    Connected accounts, cardholders, and cards
    Embed card management UI
    Credit
    Overview
    Set up connected accounts
    Manage credit terms
    Report other credit decisions and manage AANs
    Report required regulatory data for credit decisions
    Manage account obligations
    Test credit integration
    Additional information
    Choose a cardholder type
    Customer support for Issuing and Treasury
    Issuing watchlist
    Marketing guidance (Europe/UK)
    Product and marketing compliance guidance (US)
Treasury
Manage money
HomeMoney managementIssuing cards

Fraud challenges

Learn about fraud challenges, an additional layer of verification for authorizations.

Copy page

Turn on fraud challenges to:

  • Minimize accidental blocks on transactions that appear fraudulent, but are in fact legitimate
  • Conduct additional verification on authorizations Stripe deems high risk
  • Conduct additional verification on authorizations you determine require it

Fraud challenges allow your cardholders to retry non-fraudulent transactions that would otherwise be blocked by fraud controls. When fraud challenges are enabled and a transaction is declined for fraud, Stripe sends the cardholder an SMS message. They can verify whether the transaction was fraudulent by replying to the message. All cardholders with an associated phone number can use fraud challenges.

Before you begin

  • Make sure you’re collecting phone numbers for your cardholders
  • Enable fraud challenges in your card issuing settings

High-risk transactions

Stripe blocks transactions above a certain risk level. The risk level of a transaction is determined by the network you’re using. High-risk authorizations are identified by a value of suspected_fraud in the request_history.reason field, and won’t trigger issuing.authorization_request webhooks when declined.

Fraud challenge flow

Stripe starts sending fraud challenges on high-risk authorizations as soon as you enable the feature in your card issuing settings.

You can see fraud challenge activity with the Authorizations API. Declined authorizations that were fraud-challenged have a value in the fraud_challenges field. Subsequent authorizations that the cardholder verifies as genuine have a value of true in the verified_by_fraud_challenge field.

The following shows an example of a fraud-challenged and declined authorization:

{ "id": "iauth_1CmMk2IyNTgGDVfzFKlCm0gU", "object": "issuing_authorization", "approved": false, ... "fraud_challenges": [{ "channel": "sms", "status": "pending" }] }

This example shows a subsequent authorization that has been verified by the cardholder:

{ "id": "iauth_1CmMk28Jx923VfJJwMCejmX", "object": "issuing_authorization", "approved": true, ... "verified_by_fraud_challenge": true }

Note

Verified, genuine authorizations trigger issuing_authorization.request webhooks. If you use real-time authorization, consider verified_by_fraud_challenge when deciding whether to approve an authorization. If your cardholder has explicitly confirmed a transaction as genuine, we recommend that you don’t apply any of your own risk controls.

To use fraud challenges, make sure that:

  • The phone number associated with your cardholder is valid and correct
  • Existing transaction decline logic in any issuing_authorization.request webhook handler doesn’t conflict with fraud challenges

Cardholder flow

Your cardholders might receive a challenge and contact your company’s customer service to learn more. Make sure your internal teams are prepared to answer questions that they might receive from your customers about these challenges.

When a cardholder receives a fraud challenge, they can override the declined transaction by verifying that the suspicious transaction is legitimate and initiated by them. Fraud challenges are only available to cardholders with an associated phone number.

The cardholder verifies the override with a one-time SMS prompt with the following language:

Did you attempt a [amount] transaction at [merchant]? Reply YES if you did, or NO if not. Reply STOP to opt out

If the cardholder replies “YES,” they receive the following:

Thanks, please wait a moment and try again.

To complete the purchase, the cardholder needs to initiate the transaction a second time. After retrying, they won’t receive the SMS prompt, and Stripe won’t block the transaction for being high-risk. If the cardholder instead replies “NO," they receive the following:

This transaction was declined. We recommend you cancel your card and request a new one. Review your account for other suspicious transactions.

Cardholders can reply “STOP” to opt out of fraud challenges, and “START” to opt back in again.

Fraud challenges for Connect platforms

If you use Connect with Stripe Issuing, turning on fraud challenges enables it for all cardholders across all connected accounts.

Availability

Fraud challenges are only available to cardholders with phone numbers in the following countries. Attempts to send fraud challenges to other phone numbers, or to cardholders who are physically outside of these countries, won’t be delivered.

  • United Kingdom (+44)
  • United States (+1)

Fraud challenges that can’t be delivered because of an unsupported country code have a status of undeliverable.

Testing

Stripe doesn’t send fraud challenge text messages to test cardholders. To help you integrate with fraud challenges, we provide helper APIs for simulating a fraud challenge flow, including sending and responding to a challenge.

Challenge a high-risk test authorization

Use helper APIs to create a test authorization. The risk level of the authorization you create is controllable: you can create a high-risk authorization by overriding the default risk assessment with a high fraud risk level.

Command Line
cURL
curl https://api.stripe.com/v1/test_helpers/issuing/authorizations \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d amount=2300 \ -d card=
{{CARD_ID}}
\ -d "risk_assessment[fraud_risk][risk_level]"=high \ -d "risk_assessment[fraud_risk][fraud_score]"=95

This authorization would be declined, with a reason of suspected_fraud in its request_history. If fraud challenges are turned on, then a fraud challenge is created for this high-risk test authorization. See Before you begin for the steps required to turn on fraud challenges.

Alternatively, you can test fraud challenges by issuing a challenge yourself. To induce a test fraud challenge, create a test authorization without a risk assessment override, and then respond to an issuing_authorization.request webhook. This method doesn’t require fraud challenges to be turned on in your Issuing settings. Learn how to trigger fraud challenges yourself in webhook responses.

Simulate a response to the fraud challenge

After inducing a test fraud challenge, you can simulate a cardholder’s response using another helper API. Call the test fraud challenge response method, passing the ID of the authorization you created in step 1, and a confirmed parameter.

Provide confirmed=true to simulate the cardholder responding “yes, I made this transaction, and it isn’t fraudulent.” Provide confirmed=false to simulate a response of “no, I did not make this transaction, it is fraudulent.”

Command Line
cURL
curl https://api.stripe.com/v1/test_helpers/issuing/authorizations/
{{AUTHORIZATION_ID}}
/fraud_challenges/respond
\ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d confirmed=true

Try the high-risk authorization again

If you simulated a response of “yes, I made this transaction” (confirmed=true), you can try the high-risk test authorization again. This time, the authorization won’t be declined because you simulated a scenario where the cardholder has indicated that the original, declined transaction is actually legitimate.

Command Line
cURL
curl https://api.stripe.com/v1/test_helpers/issuing/authorizations \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d amount=2300 \ -d card=
{{CARD_ID}}
\ -d "risk_assessment[fraud_risk][risk_level]"=high \ -d "risk_assessment[fraud_risk][fraud_score]"=95

This new authorization won’t be declined for suspected_fraud, and is approved. It might also be declined for other reasons (such as an insufficient test balance), look at the authorization’s request_history to learn more.

Additionally, this new authorization’s verified_by_fraud_challenge field will be true. This indicates that the cardholder has previously completed a fraud challenge for a similar authorization (as simulated in step 2).

Was this page helpful?
YesNo
Need help? Contact Support.
Join our early access program.
Check out our changelog.
Questions? Contact Sales.
LLM? Read llms.txt.
Powered by Markdoc