オーソリ成功率を最大化: ネットワークによる支払い拒否を減らす方法

このガイドではオーソリ成功率の管理の概要を説明し、正当な支払いの失敗を減らす方法をご案内します。

はじめに

支払いは、不正確なカード情報や不正使用の疑いなど、さまざまな理由により失敗する場合があります。実際に、多くの支払い拒否コードがあり、各コードは支払い拒否のそれぞれの理由を表しています。支払い拒否は、不正な取引を排除するために役立ちますが、正当な支払いの失敗にもつながる可能性があり、その結果、売上を失い、顧客体験を損なうことになります。

カード拒否への対応について、オンラインビジネスには固有の課題があります。オーソリ成功率 (送信した取引がカード保有者の銀行により承認される率) はオンライン取引の場合、対面取引に比べて 10% 低くなる可能性があります。正当な販売であっても、不正使用のリスクが高いため、カード発行銀行はオンライン取引の承認または拒否に対してより慎重なロジックを使用します。このため特定の売上を失うだけでなく、その顧客に対する以降の売上すべてを失う可能性があります。価値の高い顧客は支払い拒否を 1 度経験すると、それ以降、取引の頻度が減り、競合他社に移行することもあることがこれまでの研究で判明しています。

カード拒否の影響

ネットワークによる支払い拒否をゼロにすることはできませんが、このガイドでは、正当な支払いの失敗を減らす方法をご説明します。支払い拒否のさまざまな種類、オーソリ成功率を高める方法、Adaptive Acceptance と Smart Retries を利用して Stripe がサポートする方法をご案内します。

また支払い拒否とオーソリに関して、業界でよく使用される用語の一覧を作成しました。このガイドに不明な用語があれば、この用語集をご参照ください。

ネットワークによる支払い拒否を理解する

顧客がお客様のサイトで購入を完了すると、ペイメントプロバイダが請求の詳細情報を取得し、これを Visa、Mastercard、中国銀聯などのカードネットワークを経由してカード発行銀行 (顧客の銀行) に支払いリクエストとして送信します。

Stripe でのカード取引の流れ
Stripe でのカード取引の流れ

このリクエストには、カード保有者の住所、お客様の業種、取引金額などの詳細な情報が含まれており、この情報は ISO 8583 と呼ばれるメッセージにエンコードされています。カード発行会社は、支払いを拒否すべきケースを決定するために複雑なロジックを使用しています。具体的には、ISO 8583 メッセージには 128 のフィールドがあり、各カード発行会社は、その解釈の仕方や、組み合わせ方を選択できます。

ネットワークによる支払い拒否は、カード発行会社が拒否した支払いとも呼ばれ、顧客の銀行が取引リクエストを拒否したことを意味します。取引が拒否されるよくある理由は次のとおりです。カード残高が不足している、カード情報に誤りがあるか、情報が古くなっている、不正使用や不適切な行為の疑いがある (紛失したカードまたは盗難にあったカードが使用されているとカード発行会社がみなす場合など)。また、カード発行会社の処理が何らかの理由で一時停止している場合やカードが認証されていない場合も、支払いの失敗につながります。

オンラインでのカード支払いにおける支払い拒否の割合 (支払い拒否コードに基づく)
オンラインでのカード支払いにおける支払い拒否の割合 (支払い拒否コードに基づく)

多くの取引は一般的な支払い拒否に分類され、支払い拒否コード「05: Do not honor」が表示されます。「Do not honor」には、残高不足から、連続する複数回の支払い拒否まで、さまざまな理由が含まれます。

カード発行会社は、さまざまな理由で「Do not honor」を使用しています。発行会社のシステムは、十分な情報を提供する拒否コードを返すように設定されていない場合があります。たとえば、一部の銀行では、ほぼすべての支払い拒否を「Do not honor」に分類しています。または、不正使用のパターンを調査中であるため、取引を疑わしいものであると識別したことを公開しないなど、支払い拒否の具体的な理由を意図的に隠す場合があります。

ネットワークによる支払い拒否を管理する

支払い拒否への対応は難しく、特に支払いが失敗した具体的な理由が不明な場合はさらに困難です。そのため、多くのビジネスは支払い拒否された取引を再試行しません。一方では、再試行を頻繁に行った結果、状況を悪化させ、コストの増加を招くケースもあります。

より適切なアプローチは、支払い拒否コードのタイプと特定のカード発行会社ごとに、戦略をカスタマイズすることです。具体的には、すべての支払い拒否に包括的な戦略を適用せずに、支払い拒否の特定の理由に的を絞ることで、失敗した取引を救済する可能性を最大限に高めることができます。中には、さらに顧客セグメントの層を追加し、支払い拒否コード および カード保有者の生涯価値に基づいて戦略を変更しているビジネスもあります。

取引の拒否をもたらす要因は、ビジネスの場所やビジネスモデル、顧客ミックスなどさまざまです。ここでは、取引拒否の最も一般的な 3 つのカテゴリに基づき、多くのビジネスが支払い拒否への対応に使用できるベストプラクティスをいくつか紹介します。

Stripe では、支払い拒否への自動対応も可能です。詳しくは「オーソリ成功率を高める方法」のセクションをご覧ください。

  • 残高不足 : 顧客に別の支払い方法へ変更してもらうか、元の支払い方法の方が残高が十分である可能性が高い場合は、後日取引を再試行するための承認を得ます。顧客が米国在住である場合は、月の 1 日または 15 日 (米国の一般的な給料日) に支払いを再度行うよう依頼することもできます。定期支払いビジネスの場合は、Stripe ネットワークからのシグナルに基づき、Stripe の Smart Retries で、最も成功する可能性の高いタイミングで支払いを再試行することで、売上を回収できる場合があります。
  • カード情報が不正確または古くなっている: カード情報が不正確であることが原因で初めての顧客による支払いが拒否された場合は、単にカード情報の入力ミスである可能性が高いため、入力し直してもらうように連絡します。登録済みのカードで取引が拒否された場合は、カード情報が古くなっている可能性があります。認証情報を更新するように顧客に依頼し、ペイメントプロバイダや決済処理機関が自動カード更新機能や同様のサービスを提供して有効期限切れや更新済みのカードの番号を自動更新していることを確認します。
  • 不正使用の疑い: 不正使用の疑いがある取引を再試行するリスクは避けて、不正な支払いを検出してブロックするための不正防止および管理ツールを必ず利用します。このようなツールを利用すると、顧客や取引のより詳細な情報を得てその正当性を確認できるため、支払いを再試行すべきかどうかについてより適切に判断できます。

カードネットワークは、取引を再試行する回数に制限を設けている点に注意してください。たとえば、多くのカードネットワークでは、15 日間で 4 ~ 6 回 のみ再試行できます。

オーソリ成功率を高める方法

支払い拒否を 0 にし、100% のオーソリ成功率を実現することは、特に多額の支払いを処理する場合にはほぼ不可能と言えます。しかし、オーソリ成功率を注視していれば、ネットワークによる支払い拒否の急増とそのタイミングを把握して、適切に対応できます。小さな改善でも、その影響は大きい可能性があります。大手企業の中には、オーソリ成功率を 0.5% 高めただけで、毎年の収入が数百万ドル増加したケースもあります。

オーソリ成功率を高めるためにできることは多数あります。以下に例を示します。

  • 追加の請求情報の収集と送信: 支払いリクエストにはできるだけ多くの情報を記載します。これにより、銀行はより多くの詳細情報を得て正当な取引を確認できます。特に、米国や英国では、郵便番号やセキュリティコードを渡すことで、ビジネスのオーソリ成功率は向上します。
  • 支払いフローの最適化: サービスの提供日を将来の日付に設定している場合、顧客に請求するタイミングと金額を見極めます。たとえば、お客様がレンタカー会社を経営しており、顧客が 1 カ月後のレンタルを予約するとします。予約時に請求しますか?それとも返却時に請求しますか?支払い方法に 10 ドルまたは 100 ドルの預かり金を設定しますか?10 ドルの預かり金のほうが現実的ですが、レンタル料が 10 ドルを超える場合は、後に全額を回収できないリスクが伴います。最適な支払いフローは、顧客体験、コンバージョン率、コストのバランスであり、ビジネスごとに異なります。
  • 不正使用率を低く抑える : チャージバック率 (支払いについて銀行に異議申し立てを行う顧客の数) が高いビジネスでは、支払い拒否率が高い傾向があります。Radar for Teams のような機械学習型の不正対策ソリューションを利用することをお勧めします。このソリューションでは、リスクの許容度に応じて疑わしい支払いをどの程度積極的にブロックするかを選択したり、カスタムルールを作成したり、高度な不正使用のシグナルを得ることができます。
  • デジタルウォレットの支払いを取り扱う: Apple Pay や Google Pay は、顧客がパスワードや生体認証 ID を入力する 2 段階認証を採用しているため、より高い受け入れ率につながります。
  • 自動カード更新機能の有効化 : ペイメントプロバイダや決済処理機関が自動カード更新機能を提供していることを確認します。この機能は、有効期限切れになった、または更新されたカードの番号を自動的に更新し、支払い拒否を減らします。専門的な会計サービスを提供している Bench Accounting は、Stripe の自動カード更新機能によって、2017 年に 12% の売上を回収しました。
  • 必要に応じて支払いを認証: 顧客の銀行が 3D セキュアに対応している場合は、特定の支払いを認証しなければならないことがあります (顧客に指紋の使用やパスワードの入力を求めるなど)。Stripe の PaymentIntents API では、可能な場合は SCA 免除を自動的に要求し、どうしても必要な場合にのみ認証を要求することでコンバージョンを最大化します。
  • Stripe のローカルアカウントの設定: グローバル展開に合わせて、Stripe のローカルアカウントを新たに作成します。新しい国でも同一の Stripe API インフラストラクチャを利用するため、追加の開発作業なしで展開できます。(銀行は国内支払いのほうが承認する可能性が高いため) 現地で最適化されたアクワイアリングサービスを使用することで、受け入れ率を最大限に高め、顧客の海外手数料や外貨両替手数料を抑えることができます。

このようなベストプラクティスは、顧客に定期的に請求したり、保存されている支払い情報を使用したりする、継続的な売上のあるビジネスにも適用できます。ただし、継続的な売上のあるビジネスや定期支払いビジネスに特有のオーソリ成功率を高める方法は他にもあります。

  • 顧客アウトリーチの自動化 : 支払いの失敗が毎月数えられる程度なら、顧客ごとに電話やメールで、必要な対応を依頼することは難しくありません (支払い方法の変更や支払い情報の更新など)。しかし、ビジネスが成長し、多数の顧客について支払い拒否を管理する必要がある場合は、このアプローチで管理するのは困難です。より拡張性の高い方法で顧客とコミュニケーションを行うには、支払いが拒否された場合に、支払い失敗のメールを自動送信する方法があります。
  • 再試行頻度の変更 : 多くの企業は、失敗した取引を 7 日ごとなどの設定されたスケジュールで再試行します。このプロセスは dunning (督促) と呼ばれています。さまざまな督促の頻度を試して自社のビジネスに最も効果的な方法を見極めるか、督促プロセスを自動化し、顧客の希望に合わせて調整できるペイメントプロバイダを探します。
  • 別の支払いプランの作成: 残高不足による支払い拒否が多いビジネスの場合は、顧客への請求方法をより柔軟なものにすることを検討します。たとえば、年間プランのみ提供している場合は、顧客がキャッシュフローを管理しやすいように、月単位または四半期単位のプランを作成することを検討します。

Stripe が提供するサポート

Stripe のソリューションは、正当な支払いの拒否を防ぐことで、ビジネスに数十億もの売上増加をもたらしてきました。Stripe の決済インフラは可用性が高く、決済処理機関のダウンタイムによる支払い拒否を防ぐのに役立ちます。Stripe では、決済処理機関のダウンタイムが発生しても、最適な接続に支払いを動的にルーティングできます。たとえば、Visa の米国データセンターでメンテナンスによるダウンタイムが発生した場合、Stripe は自動的に処理量を移動します。また、Stripe は 6 つの主要なグローバルカードネットワークに直接組み込まれているため、システム間のハンドオフによるシステムエラーの可能性が低減されているだけでなく、特定の取引結果に関する詳細なデータを収集できます。

Stripe を利用してオーソリ成功率を高めるには、Adaptive Acceptance、Smart Retries、自動カード更新機能の 3 つの方法があります。

Adaptive Acceptance

Stripe の Adaptive Acceptance は、機械学習モデルを使用して、カード発行会社によって拒否された支払いが顧客に返される前に、選択的にリアルタイムで再試行します。Stripe は、支払いリクエストのさまざまな要素を動的に調整して受け入れ率を高めると同時に、さまざまなカード発行会社を対象に何回も試すことで、成功につながる可能性が最も高い方法を瞬時に把握します。たとえば、英国の顧客の中に、郵便番号をスペースを入れずに小文字でチェックアウトフォームに入力するユーザがいるとします。Stripe はこのパターンを認識した上で、特定の郵便番号形式がその他の形式よりも高いオーソリ成功率を得られるかどうかを見極めるためにさまざまなバリエーションをテストします。このようなテストをさまざまなカード発行会社を対象に同時に実行することで、機械学習モデルは銀行ごとに最も効果的な方法を学習します。

Adaptive Acceptance の流れを示します。支払いが拒否されると、Stripe は、機械学習を利用して理由を把握し、設定を最適化した上で選択的に支払いを再試行します。
Adaptive Acceptance の流れを示します。支払いが拒否されると、Stripe は、機械学習を利用して理由を把握し、設定を最適化した上で選択的に支払いを再試行します。

Smart Retries

経常収益型のビジネスでは、 請求サイクルの最初に支払いが拒否されても、売上を回収する時間があります。多くのビジネスは、取引に失敗すると、後に再試行を行いますが、これは、督促と呼ばれます。 通常、督促のアプローチでは、7 日後に再試行し、さらに 7 日後に再試行するというように、時間ベースの非常に基本的なロジックを使用します。Stripe では、Smart Retries と呼ばれる、より洗練されたアプローチを構築しています。Smart Retries では機械学習や、Stripe ネットワーク全体で参照できる膨大な情報を利用します。たとえば、カード発行会社の対応 (カード発行銀行が審査のしきい値を変更する場合など) やカードの更新を確認し、Stripe 全体におけるアクティビティを分析して、支払い方法が正常に使用されているかどうかを確認します。Stripe はこの情報を利用して、失敗した支払いの再試行に最適なタイミングを選択し、請求書の支払い成功率を高めます。

Stripe Smart Dunning

自動カード更新機能

物理カードがカード発行会社によって差し換えられた場合でも、取引は保存された支払い情報で引き続き処理できますが、多くの場合、支払い拒否が発生します。 Stripe はカードネットワークと連携し、顧客が新しいカードを受け取ると (期限切れのカードや、紛失または盗難の報告があったカードの差し替えなど)、保存されているカードの情報を自動的に更新します。 そのため、顧客は中断することなくサービスを利用し続けることができ、お客様はカードが差し替えられるたびに新しいカードの情報を収集する必要が減り、支払い拒否の発生を抑えることができます。

カード情報の自動更新はアメリカで広くサポートされており、Stripe は、アメリカン・エキスプレスや Visa、Mastercard、およびディスカバーのカードのほとんどを自動更新できます。アメリカ以外での対応は国によって異なります。

Stripe はこのような技術を使用して、正当な支払いの拒否を動的に防ぐことで、ビジネスの収益を数十億ドル増やしてきました。

Stripe を利用した、拒否された支払いの回復について確認する

支払いに関する用語集

オーソリ率

取引リクエストを送信し、カードネットワークに承認された取引の割合

自動カード更新機能

主要カードネットワークのすべてとの連携によって、顧客の期限切れカードや更新カードの番号を自動更新して、支払いの失敗を低減する機能。

カードネットワーク

加盟店とカード発行会社の間の取引を処理し、クレジットカードを承認できる状況を管理します。またネットワークコストも管理します。この例として、Visa、Mastercard、アメリカン・エキスプレスなどが挙げられます。

支払い拒否コード

取引拒否の理由を示す番号 (「05」など) や文言 (「expired_card」など)。

Do not honor (支払わない)

最も一般的な支払い拒否コード。「Do not honor」は、一般的な支払い拒否を指します。カード発行銀行は、取引拒否の理由を伝えることなく、詳細については顧客から銀行に問い合わせるように求めます。

督促

経常収益型ビジネスで、拒否された支払いや失敗した支払いを回復するためのプロセス。

不正使用

不正または違法な取引。 一般的な例では、カード番号や普通預金口座のデータを盗み、その情報を使って不当な取引を行います。

発行銀行

カードネットワークの代理として消費者にクレジットカードやデビットカードを発行する銀行。

ネットワーク承認率

発行銀行によって承認または拒否される取引の割合。拒否の発生原因には、認証情報が古い、不正使用の疑い、資金不足などがあります。

ネットワークによる支払い拒否

発行会社の支払い拒否とも呼ばれます。ネットワークによる支払い拒否は、顧客の銀行が取引リクエストを拒否したことを意味します。

ガイド一覧に戻る
You’re viewing our website for Norway, but it looks like you’re in the United States.