Fraud challengesBeta
Turn on fraud challenges to:
- Minimise accidental blocks on transactions that appear fraudulent, but are in fact legitimate
- Conduct additional verification on authorisations that Stripe deems high risk
- Conduct additional verification on authorisations that you determine require it
Fraud challenges allow your cardholders to retry non-fraudulent transactions that would otherwise be blocked by fraud controls. 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 authorisations 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 authorisations as soon as you enable the feature in your card issuing settings.
You can see fraud challenge activity with the Authorisations API. Declined authorisations that were fraud-challenged have a value in the fraud_challenges field. Subsequent authorisations 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 authorisation:
{ "id": "iauth_1CmMk2IyNTgGDVfzFKlCm0gU", "object": "issuing_authorization", "approved": false, ... "fraud_challenges": [{ "channel": "sms", "status": "pending" }] }
This example shows a subsequent authorisation that has been verified by the cardholder:
{ "id": "iauth_1CmMk28Jx923VfJJwMCejmX", "object": "issuing_authorization", "approved": true, ... "verified_by_fraud_challenge": true }
Note
Verified, genuine authorisations trigger issuing_authorization.request
webhooks. If you use real-time authorisation, consider verified_by_fraud_challenge
when deciding whether to approve an authorisation. 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 will not 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.
Trigger fraud challenges yourself
To send fraud challenges on authorisations that haven’t been blocked by Stripe, use real-time authorisation webhooks. To trigger challenges in scenarios where you detect spending that appears suspicious and want additional verification (for example, a cardholder using their card out of the country), decline the issuing_authorization.request
webhook and include the send_fraud_challenges
field with the ["sms"]
value.
Here’s an example of how to trigger a fraud challenge in a webhook response:
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.