Last updated on 29 Oct 2024.
On 15 March 2024, a set of industry guidelines that outline security measures for businesses that conduct card payments in Japan, the "Credit Card Security Guidelines,” was revised (Credit Card Security Guidelines Version 5.0).
The Credit Card Security Guidelines state that merchants who conduct online sales (Stripe users) must enable 3D Secure by the end of March 2025 in order to combat fraud.
3D Secure (3DS) is a mechanism that provides an additional layer of authentication for credit card payments and protects businesses from liability for fraudulent card payments.
Stripe will require 3DS on all applicable payments from 31 March 2025. In some cases you can decide whether or not to use 3DS.
In January 2025, Stripe will start to require 3DS on a small percentage of payments, and gradually increase this to 100% of payments by 31 March 2025, excluding payments that are exempt from the 3DS requirement. You must make any necessary changes to your Stripe integration by the end of 2024 to avoid payment failures.
If your preparations for 3DS extend beyond December 2024, you can request to be excluded from the January timeline, but Stripe will still require 3DS on all applicable payments from 1 April 2025.
Credit card payments on older APIs that do not support 3DS (Charges API and Orders API) will start to require 3DS, and therefore fail, from April 2025. By 30 June 2025, all credit card payments on these APIs will fail.
There are cases where you can decide whether or not to apply 3DS. When payments are made without 3DS by using an exemption, liability shift for fraudulent payments doesn’t apply. Please refer to our documentation to see how Stripe implements 3DS exemptions.
If you already use Stripe, you may need to check your integration to ensure 3DS is supported.
We recommend using Stripe’s test card numbers to check that your integration works with 3DS. You can learn more about testing in our documentation.
Neither the Charges API nor the Orders API support 3D Secure 2. As a result, if your account uses these legacy APIs, credit card payments will fail. We strongly recommend that you migrate to the Payment Intents API as soon as possible to avoid failures.
You’ll need to ensure that your integration can handle the requires_action state to prompt your customers to authenticate their payments. You may need to update your integration to handle card authentication.
Also if you finalise payments on the server, you need to take additional steps to show the 3DS authentication flow on the client. Refer to this guide for more details.
You’ll need to either upgrade to version 2019-03-14 or newer of the API, or use the payment_behavior parameter as described in this guide to ensure that the initial payments of your customers’ subscriptions are authenticated.
If you use Stripe through a third-party integration or third-party platform, you’ll need to check directly with them to learn about their readiness.
Be prepared for questions from your customers about 3DS. Also, if necessary, ensure that any necessary support content for your customers describes the 3DS requirement.
Stripe Radar helps prevent fraud by analysing payment data from over a million companies worldwide and detecting and blocking fraudulent payments. Radar uses machine learning to conduct risk assessments based on hundreds of signals, including card type, country of use, device, and behaviour. Stripe offers three default Radar rules that dynamically request 3DS. By setting these rules in the dashboard, additional authentication can be requested from customers when their card issuing company requires 3DS.
With Radar for Fraud Teams, which allows for custom rule settings, businesses can tailor their own unique risk management settings for 3DS. 3DS requests can be made based on risk levels or specific metadata, helping prevent excessive blocking of legitimate payments, reduce the decline rate of payments, and maximise revenue.
Use of Radar may help to mitigate loss of conversion while allowing for risk-based anti-fraud measures. Additionally, Radar can be used to conduct the required risk analysis for Customer-Initiated payments against saved cards.
Transactions where a physical card is used in person are out of scope.
There is no fine, but a merchant investigation may be issued through Stripe or the acquirer, who can instruct the merchant to enact necessary security measures if the merchant has not taken appropriate steps to prevent fraudulent use and protect credit card numbers. If, regardless of such instructions, a merchant does not adopt the security measures, they may be offboarded as a merchant.
In most cases, there are no additional fees for 3DS. However, if your account has a custom pricing plan, you may incur fees for each 3DS attempt.
If you're using Stripe through a third-party integration or plugin, you may still need to make changes to comply with the new 3DS requirements. The exact steps will depend on your third-party provider's implementation. We recommend reaching out to your third-party or plugin provider as soon as possible to confirm that they're preparing for these regulations and to understand any updates you might need to make on your end.