強力な顧客認証への対応
強力な顧客認証規制がビジネスに与える影響、およびそれに対応するために組み込みを更新する方法について説明します。
強力な顧客認証 (SCA) は、ヨーロッパの PSD2 規制の一環として 2019 年 9 月 14 日に施行されたルールです。新たに SCA が施行されることで、ヨーロッパの顧客はオンライン決済の認証方法を変更する必要があります。カード支払いの場合、SCA 要件を満たすには 3D セキュアを使用しなければなりません。取引が新しい認証ガイドラインに準じていない場合、顧客の銀行が取引を拒否することもあります。
To support SCA:
- Determine if SCA impacts your business.
- Decide which SCA-ready product is right for your business.
- Make changes now to avoid declined payments.
If you use a third-party plugin, platform, or extension partner, contact your Stripe partner to see if changes are required to support SCA. Contact support if you have any questions.
影響が及ぶビジネスおよび支払い
Update your Stripe integration to support SCA, if all of the following apply:
- Your business is based in the European Economic Area or you create payments on behalf of connected accounts based in the EEA.
- You serve customers in the EEA.
- You accept cards (credit or debit).
While some low-risk transactions (based on the volume of fraud rates associated with the payment provider or bank) don’t require authentication, banks can still request that the customer complete authentication. Even if you’re primarily processing low-risk transactions, update your integration so your customers can complete authentication when requested by the bank. Learn about SCA exemptions.
SCA 対応の製品と API
1 回限りの支払いを回収する場合でも、後で再利用するためにカードを保存する場合でも、Stripe は SCA 要件を満たすのに役立つ事前構築済みのカスタマイズ可能なプロダクトを提供しています。
レガシーの Charges API を使用するなどして、SCA に対応していないシステムは、SCA を施行している銀行からの支払い拒否率が高くなる可能性があります。
1 回限りの支払い
Payment Intents API と Checkout (SCA 要件を自動的に処理する事前構築済みの Stripe のオンライン決済フロー) を使用して、カード支払いを受け付けます。Checkout はカスタマイズ可能で、1 回限りの購入とサブスクリプションの両方の支払いをウェブサイトで受け付けられるようになります。
Re-using cards
Save a card for later reuse with the Payment Intents API and the Setup Intents API. You can also use Checkout to automatically handle SCA requirements, or use Billing to handle SCA for subscriptions.
SCA 移行
You might need to update your integration to support SCA. For details about the changes to make, including for specific product recommendations based on use case, see the following guides:
Update plugins and developer libraries 
You might need to update your Stripe plugin or developer library to support SCA. If you’re looking for an SCA-ready plugin, visit Stripe Partners.
Identify your plugin on our platform 
Include identifying information in your plugins and third-party libraries so we can contact you about future changes or critical updates to the API. Use the setAppInfo function to provide those details in your Stripe integration.
Stripe パートナープログラムへの参加をお勧めします。このプログラムには無料で登録でき、プラグインを構築するための多くの開発者向けリソースが含まれています。提案されるベストプラクティスをご覧ください。
Determine your integration path 
以下の点をご検討ください。
- Use Stripe Checkout to collect payments using a customizable form. You can embed the payment form on your website or host it on Stripe.
- For more control over your checkout flow, use the Payment Intents API and Setup Intents API with Elements, PaymentMethods, Customers, and Connect. These APIs display authentication flows like 3DS 2, save cards to use later, and support SCA.
- For recurring payments, use Stripe Billing to manage subscriptions and invoicing.
- Register a webhook endpoint for your account or connected accounts, and manage them with the Webhooks API.
これらのオプションのいずれもシステムで機能しない場合は、Stripe にお知らせください。
Test dynamic authentication 
After you implement your integration path, configure your Dynamic 3D Secure Radar rules to test your integration using 3D Secure test cards. Make sure to test both successful and unsuccessful authentication cases.
Notify your customers and Stripe 
As soon as you finish updating, provide an SCA-ready update to your customers. You can share the Strong Customer Authentication guide with your customers to help them understand these regulatory changes. When you release an SCA-ready update, notify Stripe as well. We direct users to SCA-ready solutions on the Stripe Partners page.
Use previous authorization agreements 
If you collect payments when your customer isn’t actively using your application, SCA might require your customer to re-authenticate, even if they authenticated in the past. For these off-session payments, you can use the Stripe APIs to authenticate your customer once while on-session, and then reuse the card repeatedly while off-session.
Alternatively, you can use previous authorization agreements (sometimes referred to as grandfathering) for off-session payments that meet the following eligibility period, regardless of payment amount and frequency:
- 2020 年 12 月 31 日より前に保存された EU の顧客のカード
- 2021 年 9 月 14 日より前に保存されたイギリスの顧客のカード
Stripe automatically looks for transactions made with cards prior to the dates listed above. If found, Stripe uses the previous authorization agreement for the current transaction. If the bank accepts the previous authorization agreement, the transaction is categorized as out-of-scope for SCA and can proceed without additional authentication.
If the bank declines the previous authorization agreement, the PaymentIntent status changes to requires_payment_method, and you must notify your customer to complete the payment.
Save cards after the eligibility period 
After SCA takes effect, you can use the Payment Intents API to save and reuse cards, and the Setup Intents API to qualify for off-session exemptions. You can also save cards using Stripe Checkout.
Prepare your saved cards for SCA 
For Stripe to reuse previous authorization agreements, you must use the Payment Intents API and tell Stripe the payment is off-session.
Before the eligibility period | After the eligibility period |
---|---|
You saved the card by passing a token, source, or payment method to the Customer object. | Create a PaymentIntent with an off-session flag. |
You saved the card by creating a SetupIntent or using setup_future_usage in a PaymentIntent. | Create a PaymentIntent with an off-session flag. |
SCA enforcement 
Prepare your payment flows for SCA-readiness as soon as possible, if SCA regulations impact you. This can help prevent an increase in declines from European cards, and prepare you in case of early enforcement by banks. Learn how enforcement varies by country.
Make sure your integration is SCA-ready 
Your integration is SCA-ready when you process all of your payments using SCA-ready products, such as Checkout, Billing, the Payment Intents API, or an SCA-ready partner solution.
Additionally, do the following:
- Test 3DS authentication with our regulatory test cards to make sure your integration can handle 3DS.
- For off-session payments, set up and authenticate the card when saving the payment method, and use the API to flag off-session payments.
- If you use the Billing API for subscriptions or invoices, make sure your integration can handle incomplete statuses.
Understand incomplete, declined, or failed payments 
Payments might not succeed for reasons including incomplete, declined, or failed payments. For payments stuck in an incomplete
(Dashboard) or requires_
(API) status, do the following:
- Make sure your customer isn’t actively authenticating an on-session payment. Your customer might also have abandoned the checkout flow.
- Verify that you’re handling next actions, such as authentication.
- Set off_session to
true
when creating an off-session payment.
Banks can decline payments that require 3DS authentication but don’t have 3DS enabled.
If an off-session payment fails, but you think it’s exempt from SCA requirements, do the following:
- Make sure you authenticate the card when saving payment method details, either during a payment or without a payment.
- When saving cards during a payment, set
setup_
tofuture_ usage off_
.session - When saving cards without a payment, use the Setup Intents API and set
usage
tooff_
.session
Exemptions aren’t guaranteed, and off-session payments might still require authentication by the bank.
View declined payments
In the Dashboard, go to Transactions > Payments.
From the Filter by: status dropdown, do one of the following:
- Select Failed to view declined off-session payments.
- Select Incomplete to view declined on-session payments.
適用をクリックします。
Hover over the status badge for the reason.
不審請求の申請を監視する
When monitoring disputes, be aware that payments successfully authenticated through 3DS fall under the liability shift rule. If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer. If the card issuer applies exemptions, the payment isn’t authenticated through 3D Secure, and liability shift doesn’t apply.
Collect permission to reuse cards 
When you set up your payment flow to save a card using the Payment Intents API or Setup Intents API, Stripe marks subsequent off-session payments as a merchant-initiated transaction (MIT). These transactions require an agreement (also known as a mandate) between you and your customer.
On your website or application, minimally cover the following:
- お客様が顧客の代わりに単独の支払いまたは一連の支払いを開始することを許可する、顧客からお客様への許可
- 予測される決済頻度 (1 回限りまたは継続)
- 支払い金額の決定方法
In your checkout flow, reference the terms of the payment:
I authorize to send instructions to the financial institution that issued my card to take payments from my card account in accordance with the terms of my agreement with you.