カードの支払い拒否

カード支払いは、さまざまな理由で失敗することがあります。以下に一般的な理由を紹介します。

• 顧客の資金不足: 顧客の資金やクレジットが不足している場合、カード発行会社は取引を拒否します。資金不足による支払い拒否を最小限に抑えるには、後払い (BNPL) オプションの追加を検討します。

• カードデータの誤り: 顧客が入力したカード番号、CVV、有効期限に誤りがあった場合、カード発行会社は取引を拒否する場合があります。このような場合は、カード情報の再入力を顧客に依頼します。

• 不正行為: カード発行会社は、高額購入や短期間での大量の取引で発生し得る不正行為が疑われると判断した場合、支払いを拒否することがあります。この問題を解決するには、顧客がカード発行会社に連絡して身元を確認する必要があります。

カードの支払い拒否

顧客のカード発行会社が支払いを受信すると、自動化システムとモデルがオーソリするかどうかを決定します。これらのツールは、消費習慣、口座残高、カードデータ (有効期限、住所情報、セキュリティコードなど) のようなさまざまなシグナルを分析します。

カード発行会社が支払いを拒否した場合、Stripe は届いている支払い拒否に関する情報を共有します。この情報は、ダッシュボードまたは API で確認できます。場合によっては、カード番号の誤りや資金不足など、具体的な説明がカード発行会社から提供されることがあります。これらは、支払い拒否コードとして表示されます。

カード発行会社は、大半の支払い拒否を一般 (generic_decline) として分類するため、正確な支払い拒否の理由が不明確になります。カード情報が正しい場合は、顧客からカード発行会社に連絡して取引の拒否理由を把握するように依頼します。プライバシーとセキュリティ保護の理由から、カード発行会社は、支払い拒否の詳細について、カード保有者のみと話し合います。

ネットワークコード

支払いが拒否されるたびに、カード発行会社は 2 つのタイプのネットワークコードを提供します。

• ネットワークの支払い拒否コード: カードの発行会社から提供される 2 桁から 4 桁のコードです。拒否された支払いでカードネットワークからレスポンスコードが Stripe に届いていない場合、network_decline_code フィールドはヌルです。コードの意味は、カードネットワークごとに異なります。そのため、コードを解釈する際は、カードのブランドを考慮してください。

• ネットワークアドバイスコード: カードの発行会社から提供される 2 ～ 4 桁のコード。このコードは支払い拒否の管理に関するガイドを提供します。拒否された支払いに関するレスポンスコードがカードネットワークから Stripe に届いていない場合、network_advice_code フィールドはヌルです。コードの意味は、カードネットワークごとに異なります。コードを解釈する際、カードのブランドを考慮してください。Mastercard では、ネットワークアドバイスコードを加盟店アドバイスコード (MAC) と呼んでいます。

カードの支払い拒否を減らす

通常、不正確なカード情報 (カード番号や有効期限の誤りなど) がカード発行会社による支払い拒否の原因である場合は、誤りを修正するか、別のカードまたは支払い方法を使用するように顧客に伝えることで解決できます。たとえば、Checkout は、カードが拒否された場合に顧客にフィードバックを提供して、再試行できるようにします。

不正行為の疑いに起因する支払い拒否を回避するため、決済時に顧客にセキュリティコードと郵便番号の入力を依頼します。請求先住所など、収集する他のデータの影響は、カードのブランドや国によって異なります。支払いの拒否率が高いままの場合は、追加の顧客情報を収集することをお勧めします。また、3D セキュアを実装して支払いを認証すると、3D セキュアをサポートする国での支払いの拒否率が低くなる可能性があります。

一般的または do_not_honor の支払い拒否でカード発行会社がカードを拒否した理由を明確に把握するには、関連データを調べます。たとえば、顧客がカードを追加したときにセキュリティコードまたは住所確認サービス (AVS) のチェックで失敗する場合、別の支払いを開始する前に、これらの両方の詳細を確認するように顧客にリクエストします。

顧客がある国で発行されたカードを使用しながら、別の国の IP アドレスから操作している場合は、許可されていないカードが利用されている可能性があるために支払い拒否が正当である場合があります。ただし、特に顧客が海外旅行中にさまざまな場所でカードを使用する場合など、例外もあります。

カードタイプの制限

一部の顧客のカードでは、購入可能なアイテムのタイプに制限があります。FSA または HSA のカードは、多くの場合、特定のタイプのビジネス (医療提供者など) に限定されているため、カード発行会社は他のタイプの購入を拒否します。さらに、カード発行会社によっては、特定の国または自国以外からの購入を許可しない場合があります。いずれの場合も、顧客がカード発行会社に問い合わせて、適用されている制限があるかなどを確認する必要があります。

地理的な場所の影響

Stripe アカウントが登録されている国とは異なる国で発行されたカードを顧客が使用している場合、支払い拒否率が上がる可能性があります。これを解決するには、顧客からカード発行会社に連絡して支払いのオーソリを求める必要があります。グローバルな顧客基盤があり、さまざまな場所を拠点としている場合、大きい方の市場、または支払い拒否率が高めの地域で Stripe アカウントを設定することをお勧めします。このようにすることで、現地として支払いを処理できます。

拒否されたカードの再試行

支払いが拒否された場合、Stripe は、支払い拒否の理由を提供して、解決パスを簡潔に提案します。

残高不足のために拒否された支払い

Stripe Billing ユーザーは、サブスクリプションのカスタムのリトライスケジュールを作成できます。Smart Retries を使用して、失敗した支払いの再試行に最適な回数を選択します。カードネットワークでは、同じ支払いを再試行できる回数に制限があることに注意してください。再試行が許容される支払いの場合、再試行回数を 8 回以内にすることをお勧めします。この回数を超えて再試行が行われると、カード発行会社によって不正利用の可能性があると判断されることがあり、その影響により正当な支払いが拒否される頻度が上がる場合があります。

API では、結果の理由は支払い拒否コードを使用して、カード発行会社がオーソリを拒否した理由を示します。outcome の advice_code は、次に何をすべきかを示します。

支払い拒否をプログラムで管理する

支払い拒否をプログラムで処理するには、いくつかの方法があります。

• PaymentIntent (支払いインテント) オブジェクトから last_payment_error.decline_code プロパティを取得して、カード発行会社が支払いを拒否した理由を確認します。
• PaymentIntent の試行された支払いを繰り返し、失敗メッセージを調べます。
• Webhook を使用して、PaymentIntent ステータスの更新を監視します。たとえば、payment_intent.payment_failed イベントは、支払いの試行が失敗したときに生成されます。

また、顧客が決済プロセスを実施している場合 (オンセッション) や、実施していない場合 (オフセッション) など、支払いの失敗の状況の管理がさらに必要になることもあります。システムを開発する際、予期しないエラーを含む、想定可能な API のあらゆる例外を処理することをお勧めします。

オンセッションの支払い拒否

顧客がお客様のウェブサイトまたはアプリケーションの決済フローを実施している場合は、支払い方法の再試行や、別の支払い方法の入力を顧客に求めます。

オフセッションの支払い拒否

顧客が支払いを行ったり、支払い方法を更新したりできない場合は、(メールやアプリ内通知を送信するなどの方法で) 顧客に通知して、ウェブサイトまたはアプリケーションにアクセスしてもらいます。貴社が強力な顧客認証 (SCA) などの規制による影響を受けている場合、支払い時にも認証が必要になり、authentication_required 拒否コードで支払いが失敗する場合があります。このような状況への対処方法について、詳細は保存されたカードでのオフセッションの支払いをご覧ください。