オーソリ成功率の最大化: カード取引の不承認を減らす方法

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

はじめに

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

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

カード拒否の影響

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

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

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

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

Stripe でのカード取引フロー
Stripe でのカード取引フロー

このリクエストには、カード保有者のカード番号、取引額などの詳細が含まれ、多くの場合、ISO 8583 と呼ばれるメッセージに変換されます。カード発行会社は、複雑なロジックを使用してどのような場合に支払いを拒否するかを決定します。ISO 8583 メッセージには、128 のフィールドがあり、カード発行会社のそれぞれが各フィールドを解釈して、組み合わせを選択します。

ネットワークによる支払いの不承認は、カード発行会社による支払い拒否とも呼ばれ、顧客のカード発行会社が取引リクエストを拒否したことを意味します。一般的な理由は、カードの残高不足、カード情報が間違っているか無効、不正使用または不適切な行為の疑いがある (紛失または盗難カードの使用が考えられる場合など) のいずれかです。また、何らかの理由でカード発行会社の処理が一時停止している場合や 3D セキュアなどによる認証が不十分な場合も、支払いの失敗につながります。

オンラインカード決済の代表的な不承認理由の割合 (拒否コード別)
オンラインカード決済の代表的な不承認理由の割合 (拒否コード別)

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

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

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

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 のスマートな督促

自動カード更新機能 (洗い替え機能)

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

自動カード更新機能はアメリカで広くサポートされているため、Stripe はほとんどの American Express、Visa、Mastercard、Discover カードを自動的に更新できます。

Stripe はこのような技術を使用して、正当な支払いの不承認を動的に防ぐことで、ビジネスに数千億円もの追加の収益をもたらしてきました。

拒否された支払いを Stripe で回収する方法についてもっと知る

支払いに関する用語集

オーソリ成功率

送信した取引の中で、カードネットワークによって承認された取引の割合。

自動カード更新機能/洗い替え機能

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

カードネットワーク

日本ではカードブランドとも呼ばれ、加盟店とカード発行会社の間で取引を処理し、どこでクレジットカードが受け付けられるかを管理します。またネットワークコストも管理します。Visa、Mastercard、American Express、JCB などが例として挙げられます。

支払い拒否コード

取引が不承認となった理由を示す番号 (「05」など) または文言 (「expired_card」など)。

Do not honor (承認しない)

最も一般的な支払い拒否コード。「Do not honor」はさまざまな理由による支払い拒否を意味します。カード発行会社は、取引が拒否された理由を伝えることはせず、代わりに、詳細についてを発行会社に問い合わせるように顧客に促します。

督促

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

不正使用

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

カード発行会社

カードネットワークに代わり、クレジットカードまたはデビットカードを顧客に発行する会社。

ネットワーク承認率

カード発行会社によって承認または拒否された取引の割合。認証情報が古い、不正使用の疑い、または残高不足などの理由から支払いは拒否されます。

ネットワークによる支払いの不承認

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

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