Last updated on Oct 29, 2024.

On March 15, 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 authentication by the end of March 2025 in order to combat fraud.

3D Secure authentication (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’s 3DS rollout timeline

Stripe will require 3DS on all applicable payments from March 31, 2025. In some cases you can decide whether or not to use 3DS.

In January 2025, Stripe started to require 3DS on a small percentage of payments, and gradually increase this to 100% of payments by March 31, 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 April 1, 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 June 30, 2025, all credit card payments on these APIs will fail.

Applicable payments

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.

Check your integration

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.

If you’re on the Charges API or Orders API

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.

If you’re on the Payment Intents API

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 finalize 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.

If you’re using Billing with API version earlier than 2019-03-04

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.

Communicate with your customers

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.

Using Radar and Radar for Fraud Teams

Stripe Radar helps prevent fraud by analyzing 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 behavior. 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 maximize 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.

FAQ

Are in-person credit card transactions out of scope?

Transactions where a physical card is used in person are out of scope.

Merchants in Japan are required to enact security measures under the Installment Sales Act, but is there a penalty if merchants do not follow these requirements?

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.

Are there any fees associated with 3DS?

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.

What if I'm using Stripe through a third-party integration?

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.

How can I test that 3DS is functioning correctly?

You can use a test API key along with test cards to create test transactions. By using test cards that require authentication, you can validate the 3DS authentication.

Is it mandatory even if I'm accepting payments from customers outside Japan?

For accounts in Japan, you need to comply with the new 3DS requirements for both domestic and international cards. Accounts outside Japan are not subject to this requirement.

How can I manually trigger 3DS?

Even if there are exceptions for 3DS, it may be desirable to incur a liability shift by manually triggering 3DS due to suspected fraud. You can do this by using Radar rules on the dashboard or using the API.

• Stripe provides default Radar rules, and you can add custom 3DS rules using Radar for Teams.
• For API, when creating or confirming a PaymentIntent or SetupIntent, or when creating a Checkout session, you can set payment_method_options[card][request_three_d_secure] to any or challenge depending on your optimization target to manually trigger 3DS.

Will authentication be in the challenge flow or frictionless flow?

Basically, this is determined by the risk assessment made by the card issuer.

• The challenge flow is additional authentication that occurs when the transaction is deemed to be high risk. Typically, a one-time password is sent via email from the card issuer to the cardholder, who then inputs it on the payment screen.
• If the card issuer assesses the transaction as low risk, they may opt not to require additional authentication, which is termed the frictionless flow.

Both scenarios result in a liability shift. If you want to specify the challenge flow in the Payment Intents API, set ‘request_three_d_secure’ to challenge.

What should I do if I want to collect card information from customers in advance and bill them later?

If your business involves saving cards in advance, you need to verify that the customer logging in is indeed the account holder. You must implement strict account management and measures against unauthorized logins.

You can implement this using the Setup Intents API, whereby Stripe will automatically trigger 3DS under the following conditions, or utilize the setup mode in Checkout to trigger 3DS by default during card registration.

• usage: off_session (default)
• usage: on_session & payment_method_options.card.request_three_d_secure: any

If 3DS authentication has been completed during card registration, it will be exempt for subsequent transactions. However, for each transaction, you should assess the fraud risk based on transaction amount, goods/services, attributes, and behavioral analysis, and if deemed necessary, you will need to perform 3DS authentication again. In such cases, use SetupIntent once more.

What should I do if my business model involves one-time payments from customers?

First, please verify that your existing payment flow functions correctly with 3DS test cards.

Even if no basic additional work is needed, it is advisable to verify that your system processes 3DS.

What should I do if I accept subscriptions?

First, please verify that your existing payment flow functions correctly with 3DS test cards.

• If you want to trigger 3DS when entering card details, please refer to the section "What should I do if I want to collect card information from customers in advance and bill them later?"
• If you do not trigger 3DS when entering card details and want to trigger it during the first payment, specify usage as on_session.

If you use the Subscriptions API and don't create a SetupIntent object manually after card entry, one will be created for you if 3DS is required. You'll need to handle this on your frontend to allow your user to complete 3DS authentication.

For recurring payments, if 3DS authentication has been completed at the time of card registration or the first payment, it can be exempted for subsequent payments, and you will not need to perform 3DS authentication. However, if there are any customer interactions related to contract changes or additional purchases, you will need to perform 3DS authentication again.