Issuing の不審請求の申請

Issuing を使用し、取引に対して不審請求を申請する方法をご紹介します。

取引に関する問題が発生した場合、顧客またはカード保有者は、支払いに対して不審請求を申し立てることができます。一般的な問題として、不正利用、商品 / サービスの未着、処理エラーなどが挙げられます。

Stripe では、不審請求を申し立ててから解決するまでのプロセスを監視するための、ガイド付きのダッシュボードプロセスと API を提供しています。このプロセスは通常 30 日から 90 日かかります。処理する不審請求の申請件数が少ない場合は、ダッシュボードを利用することをお勧めします。不審請求の申請件数が多い場合は、API の使用をお勧めします。

不審請求の申請を行う前の考慮事項

ネットワーク規則

Stripe は、取引を処理したカードネットワークの規則とガイドラインに従って不審請求の申し立てを処理しています。このドキュメントの内容は簡略化されています。不審請求の申し立てに適用されるルールおよびガイドラインの詳細は、Visa および Mastercard のルールブックをご覧ください。

有効な不審請求の申し立て

不審請求は、取引につき 1 回のみ申し立てることができます。提出後に、追加で編集したり反証資料を捕捉したりすることは認められません。顧客は、カードネットワークの定める要件に沿って不審請求を申し立てることに責任を負います。無効または不完全な不審請求を申し立てた場合、主張が認められなくなる可能性があります。

消費者による不審請求の申し立て

顧客が不審請求の申し立て (例: 未受領、キャンセル、説明と異なる) を行う場合、カード保有者は申し立て前にビジネスとの間で不審請求の解決を図る必要があります。不審請求の申し立てを行うにあたり、カード保有者が不審請求の解決を図るための資料を添付する必要があります。

カードネットワークの不正利用の定義

Visa と Mastercard の両方において、不正取引とは、カード保有者が支払いへの関与を否定している取引を指します。カード保有者が取引に関与したことを認めた場合 (詐欺など)、不審請求の申し立ては、カード保有者の不審請求権が認められる別の理由で行う必要があります。

不正利用に関する不審請求の申請要件 (プラットフォーム向け)

プラットフォームは、連結アカウントが、API または埋め込みコンポーネントを使用してプラットフォームとして表示するダッシュボードを通じて、Stripe に不正利用に関する不審請求の申請を直接提出できるようにする必要があります。このような申請を提出する機能をいかなる方法でも制限することはできません。不正利用に関する不審請求の申請が提出された後、Stripe 側で審査し、カード保有者に返金する必要があるかどうかを判断します。

ブロックされた申請の提出

取引が現地の規制に基づく不正防止の要件を満たしておらず、アカウント所有者にネットワーク規則に基づく申請の権利がない場合、Stripe は不正利用による不審請求の申請の提出をブロックすることがあります。

プラットフォーム向け

不審請求の申請を提出する義務があり、実際に提出した場合、Stripe が提出をブロックしたかどうかに関係なく、義務を果たしたことになります。

カードネットワークは、以下の理由 (または、他の理由) により不審請求の申請を無効と見なすことがあります。

取引が返金であり、キャプチャーではない。
取引がモバイルプッシュ支払い取引である。
申請期限切れ

ダッシュボードの「取引を不審請求として申請」ボタンは、対象となる取引に対してのみ有効になります。API では、対象外の取引に対して不審請求を申請しようとするとエラーになります。

有効期限

各カードネットワークは、不審請求の申請期限を設けています。この期限を過ぎてから行われた不審請求の申し立ては期限切れと見なされ、主張が認められません。期限は、不審請求の申請理由やカードネットワークによって異なります。

Visa の場合、不正利用や処理エラーに関する不審請求は、取引日から 110 日以内に申し立てを行う必要があります。「オーソリ」に不審請求を申し立てる場合は、取引日から 65 日以内です。「キャンセル」、「未着」、「説明と異なる」などを理由とする不審請求の申し立ては、商品 / サービスの受領予定日から 110 日以内に行う必要があります。

一部の金額

不審請求は、支払い額の全額または一部に対して申し立てることができます。返金がある場合は、その処理を行った後で不審請求の申し立てを部分的に行います。不審請求の申請理由 (金額の誤りなど) によっては、部分的な金額に対してのみ不審請求を申し立てる必要があります。最後に、複数の顧客による不審請求の申し立てでは、商品の注文またはサービスの一部がすでに受領されているような場合、不審請求の申請額も限定されます。

ライフサイクル

ビジネス用語

上図の「企業」とは、支払いを受けるビジネスである「アクワイアラー企業」のことです。

新たに作成された不審請求の申請の初期ステータスは unsubmitted に設定されます。この時点では証拠およびメタデータを更新できます。必要な証拠をすべて追加した後で、不審請求の申請を提出できます。取引の決済から 110 日以内に申請されなかった場合、ステータスは expired に変わります。

Stripe とカードネットワークは、submitted ステータスの不審請求の申請を処理します。そのため、不審請求の申請の証拠は更新できませんが、metadata は引き続き変更できます。申請済みの不審請求の申請は、カードネットワークと加盟銀行が定義した複数ステップのプロセスに進みます。不審請求の申請が解決されると、Stripe はそれを最終的な won または lost ステータスに移行します。

作成

不審請求の申請額フィールドに、不審請求が申請された金額 (全額または一部) を入力します。フィールドの初期値は取引金額です。不審請求の申請額フィールドが未記入で提出されると、取引の全額に対して不審請求の申請が作成されます。

Issuing の不審請求の申請作成ページの不審請求の申請額フィールド

不審請求の申請を行う Transaction (取引) を指定して、Create (作成) メソッドを使用します。また、evidence オブジェクトも指定する必要があります。これに含まれる reason によってその他のフィールドが決まります。この例では、reason に値 "not_received" が指定されているため、not_received が入力されます。

詳細については、次の不審請求の申し立ての理由と証拠セクションをご覧ください。作成時の証拠のフィールドはすべて任意です。収集する証拠を柔軟に追加でるきよう、表示されます。Issuing dispute API のメソッドでは必ず、Dispute オブジェクトが返されます。

更新する

Update メソッドを使用して、未送信の不審請求の申し立ての証拠とメタデータを更新します。提出した不審請求の申し立てでは、メタデータのみを更新できます。以下の表には、更新可能な evidence が表示されています。この状態の evidence から始まると想定されます。

"evidence": {
  "reason": "not_received",
  "not_received": {
    "additional_documentation": null, // We refer to these as "evidence fields"
    "expected_at": null,
    "explanation": "Not shipped",
    "product_description": "Baseball cards",
    "product_type": "merchandise"
  }
}

アクション	入力	結果
証拠フィールドの追加、置換、削除	`"evidence": { "reason": "not_received", "not_received": { // Add "expected_at": 1590000000, // Replace "explanation": "Lost", // Remove "product_description": "" } }`	`"evidence": { "reason": "not_received", "not_received": { "additional_documentation": null, "expected_at": 1590000000, "explanation": "Lost", "product_description": "", "product_type": "merchandise" } }`
変更理由	`"evidence": { "reason": "fraudulent" }`	`"evidence": { "reason": "fraudulent", "fraudulent": { "additional_documentation": null, // Copied from "not_received" "explanation": "Not shipped" } }`
理由を記入せずに証拠フィールドを更新	`"evidence": { "not_received": { "explanation": "Lost" } }`	エラーが発生しました。`evidence` オブジェクトには必ず `reason` フィールドが含まれている必要があります。
証拠フィールドの設定をすべて解除	`"evidence": { "reason": "not_received", "not_received": "" }`	`"evidence": { "reason": "not_received", "not_received": { "additional_documentation": null, "expected_at": null, "explanation": null, "product_description": null, "product_type": null } }`

提出

送信エンドポイントでは、指定された不審請求の理由に必要な証拠がすべて揃っていることが検証されます。詳細については、不審請求の申請理由と証拠を参照してください。

注意

反証資料は提出後に修正することはできません。提出前に内容を十分に確認してください。

解決

不審請求の申請ステータスは、カードネットワークから情報を受け取った時点で更新されます。アクワイアラーの主張が認められると、不審請求の申請ステータスは lost に変更され、資金の送金は行われません。

不審請求の申請で主張が認められるとステータスは won に変わり、資金が Issuing 残高に返金されます。アカウントへの入金は、issuing_dispute タイプの残高取引の形式で行われます。

残高取引は、Dispute オブジェクトの balance_transactions に一覧表示されます。ただし、デフォルトではこのフィールドは返されません。expand フィールドを使用してリクエストしてください。詳細については、拡張のドキュメントをご覧ください。

注

取引がアカウントのデフォルト通貨とは異なる通貨で行われた場合 (たとえば、取引は GBP で支払いは USD のカードなど)、Stripe は、主張が認められた不審請求の申請に対して取引の元の通貨で返金します。

テスト

Stripe はテストの不審請求の申し立てを本番環境であるかのように処理し、想定される動作を実証します。たとえば、Webhook イベントの送信、残高取引の作成、Issuing 残高の更新などを行います。これらはすべて、不審請求の申し立てを送信してから数秒以内に行われます。

API では、explanation フィールドに “winning_evidence” または “losing_evidence” と入力されたテストの不審請求の申し立てを送信すると、不審請求の申し立てをそれぞれ won または lost ステータスに移行するよう Stripe に通知されます。それ以外の場合、不審請求の申し立ては本番環境と同様に submitted ステータスに移行します。

本番環境と同様に、テスト用の不審請求の申し立ては、取引がキャプチャーされてから 110 日後に expired に移行します。

Webhook

不審請求の申請に関する変更通知を受け取るには、Issuing 不審請求の Webhook イベントをリッスンできます。すべての Issuing 不審請求イベントには、更新後の Dispute (不審請求の申請) オブジェクトが含まれます。

Webhook イベント	トリガー
`issuing_dispute.created`	不審請求の申請が作成されました。
`issuing_dispute.updated`	不審請求の申請が更新されました。
`issuing_dispute.submitted`	不審請求の申請が提出されました。
`issuing_dispute.funds_reinstated`	資金が Issuing 残高に送金されました (通常 `won` ステータスの不審請求の申請に関連付けられます)。
`issuing_dispute.funds_rescinded`	Issuing 残高から差し引かれる資金 (通常は暫定的なクレジットクローバックに関連付けられます)。
`issuing_dispute.closed`	不審請求の申請のステータスが `won`、`lost`、または `expired` に移行しました。

不審請求の申請の理由と証拠

不審請求の申請理由によって、申し立てに必要な要件も異なります。不備のない申し立てと高品質の関連資料は、主張が認められる確率に直結します。申し立ての説得力を最大限に高めるには、明確に情報が記述された資料が必要です。

不審請求の申請は、以下のいずれかの理由で提出できます。

キャンセル済み: カード保有者が商品をキャンセルまたは返品した、またはサービスをキャンセルしたが、企業がクレジットを処理しなかった、または取引の領収書を無効にしなかった。
重複:処理エラー (取引の重複、金額の誤り、別の手段で支払い済みなど) による不審請求の申し立て。
不正利用:カード保有者が取引を承認していない。
商品が説明と異なる: カード保有者が商品を受け取ったが、購入時に提示されたものと異なっていたか、損傷または欠陥があった。
未着: カード保有者は取引に関与したが、商品またはサービスを受け取っていない。
有効なオーソリなし: (API のみ) 有効なオーソリが行われていない取引を企業が処理した。
サービスが説明と異なる: カード保有者がサービスを受けたが、購入時に提示された内容と一致しなかった。
その他:既存の申請理由に明確に該当しない不審請求の申し立てシナリオ。この理由で提出された不審請求の申し立ては、Stripe によって再分類されます。不審請求を申し立てる際は、反証資料の説明に実際の申請理由も含めるようにしてください。

ダッシュボードでは、Merchandise not as described と Service not as described は Not as described にまとめられています。

揃える必要がある証拠は理由ごとに異なります。

証拠	説明
説明	取引の説明と、カード保有者がそれに対して不審請求を申請している理由。このフィールドを使用して、他のどこにも記載されていない説明を追記することもできます。カード保有者は、自分が取引に関与していないこと、自分の知人による取引でないことを確認することが重要です。
追加書類	カード明細書や返送状況の追跡などの関連書類。ファイルは PDF 形式または JPEG 形式である必要があります。不審請求の申請を提出する前に、すべてのテキストや画像がファックスのモノクロ送信ではっきりと表示され、判読可能な十分な大きさであることを確認してください。不正利用に関する申請の評価では、カード保有者に対して請求先住所を最新に保つように促すことが重要です。

証拠

説明

取引の説明と、カード保有者がそれに対して不審請求を申請している理由。このフィールドを使用して、他のどこにも記載されていない説明を追記することもできます。カード保有者は、自分が取引に関与していないこと、自分の知人による取引でないことを確認することが重要です。

追加書類

カード明細書や返送状況の追跡などの関連書類。ファイルは PDF 形式または JPEG 形式である必要があります。不審請求の申請を提出する前に、すべてのテキストや画像がファックスのモノクロ送信ではっきりと表示され、判読可能な十分な大きさであることを確認してください。不正利用に関する申請の評価では、カード保有者に対して請求先住所を最新に保つように促すことが重要です。

不正使用の不審請求の申請

カード保有者が取引を承認していないと主張する場合、その取引に対して不正利用に関する不審請求を申し立てることができます。

不審請求を申請する前に、以下を行ってください。

カード保有者に、その取引がカード保有者の過失によるものではないこと、またはカード保有者の知人によるものではないことを確認する必要があります。たとえば、友人や家族による取引は、不正利用に関する申請には該当しません。
API 経由で不審請求の申し立てを行う場合、対象のカード決済をキャンセルします。不審請求の申し立てがダッシュボードから行われた場合、カード決済は自動的にキャンセルされます。

以下のような特定の状況では、取引の不正利用に関する申請の権利を失う可能性があります。

カード提示取引の場合: デフォルトでは責任がカード発行会社にあるため、カードネットワークは不正利用に関する申請を自動的に拒否することがあります。
カード非提示取引の場合: カードネットワークは、取引中にカード保有者が認証された場合、不正利用の申し立てを自動的に拒否することがあります。これは、3D セキュアがリクエストされた場合や、Apple Pay などの堅牢な決済手段が使用された場合によく発生します。

オーソリに関する不審請求の申請

アクワイアラー企業が取引を処理する際は、まずイシュアーにオーソリをリクエストする必要があります。有効なオーソリを取得していないまま企業が支払いをキャプチャーした場合、またはオーソリは取得したものの有効期限が切れている場合、取引に対して不審請求を申し立てることができます。選択する理由は、不審請求の申し立てを行う方法によって異なります。

API を使用した不審請求の申請: no_valid_authorization の理由を選択して不審請求の申請を提出します。
ダッシュボードでの不審請求の申し立て:other の理由で不審請求の申し立てを行い、explanation フィールドに ‘no authorization’ の理由による申し立てを入力します。

オーソリに関する不審請求の申請は、不正利用に関する不審請求の申請とは異なります。

カード保有者が取引に関与していない場合は、不正利用に関する不審請求を申し立てます。
取引で企業が有効なオーソリを取得していない場合は、オーソリに不審請求を申し立てます。

オーソリに不審請求が申し立てられるもう 1 つの理由は、オーバーキャプチャーです。オーバーキャプチャーは、キャプチャー額がオーソリ額を超える場合に発生します。オーバーキャプチャー時のオーソリに不審請求を申し立てる際は、オーソリの超過分の金額のみが含まれるように申し立て額を調整する必要があります。

注

一部の加盟店カテゴリーコード (MCC) では、特定の金額のオーバーキャプチャーが許可されたり、オーソリに関する不審請求の申請が許可されなくなります。詳細については、お客様の地域の現在のカードネットワークの規則をご覧ください。

取り下げ

Stripe は、カードネットワークに申請が提出されてから 1 日以内にのみ不審請求の申請を取り下げることができます。不審請求の申請を取り下げる場合は、すぐに Stripe サポートにお問い合わせください。

不正利用の責任

アメリカで運営されているプラットフォームの場合、 Regulation Z の大部分は事業用のカードには適用されませんが、Regulation Z は事業用のカードのユーザーを不正利用およびその他の「カードの無断使用」 (すなわち、カードの使用権限がない人物よる支払いカードの使用) から保護します。ほとんどの場合、不正利用に関する妥当な調査が実施されない限り、アカウントに関連付けられているカードの不正利用に対する責任をアカウント所有者に負わせることはできません。ただし、アカウント所有者に従業員認定ユーザーが 10 人以上いる場合は、この保護の対象にならない可能性があります。

ユーザーが取引を承認していないと考えているために取引に対する不審請求を申請した場合、Stripe は、(その他のタイプの不審請求の申請の取引と同様に) 不審請求の申請を裁定を求めてカードネットワークに送信します。Stripe またはカードネットワークが、お客様と企業のどちらが不正使用に対して支払うかを決定します。

Stripe またはカードネットワークが、不正使用に対する責任が企業にあると判断した場合は、お客様とユーザーのどちらも不審請求が申請された取引に対する責任を負いません。

Stripe またはカードネットワークが、不正使用に対する責任がお客様にあると判断した場合、不審請求が申請された取引に対して支払う必要が生じることがあります。Stripe は、不審請求の申請に対して妥当な調査を行い、不正使用が実際に行われたかどうか、また、ユーザーが Regulation Z の保護の対象とならないかどうかを判断します。調査により、無許可のカード使用が実際に行われ、ユーザーが保護の対象となることが明らかになった場合は、お客様は無許可の取引に対する責任を負うことになります。一方、調査により、無許可のカード使用が行われなかったか、ユーザーが保護の対象とならないことが明らかになった場合は、アカウント所有者が不審請求の申請に対する責任を負います。

Connect アカウントにメールを送信

Issuing プラットフォームは、不審請求の申請が送信されたときと、不審請求の申請の結果が出たときに、規制に基づく通知メールを連結アカウントに送信する必要があります。規制に基づく通知の詳細をご確認ください。。

Stripe Treasury とともに使用する

FinancialAccounts の ReceivedDebits に対する不審請求の申請が行われると、対応する DebitReversal が設定されます。