2024 年には、35.5% の侵害がサードパーティベンダーにリンクしており、決済代行業者と連携している場合、そのような侵害にはさらに高いリスクが伴います。そのため、決済の提案依頼書 (RFP)では、セキュリティと法令遵守は譲れません。RFP では、決済プロバイダーが機密データをどのように保護するか、インシデントにどの程度迅速に対応するか、規制要件をどの程度満たすことができるかなどを確認する必要があります。適切な質問をし、証拠による回答を求める必要があります。以下では、決済に関する RFP でセキュリティと法令遵守について質問する際のベストプラクティスを紹介します。

この記事の内容

• すべての決済 RFP に含めるべきセキュリティ要件と法令遵守要件とは？
  
• PCI DSS 要件を決済 RFP に書き込むにはどうすればよいですか？
  
• ベンダーに質問すべきデータ保護とプライバシーの基本的な質問とは？
  
• RFPでベンダーの不正利用防止を評価するには？
  
• ベンダーが提供すべきインシデント対応と災害復旧の詳細は？
  
• RFP でグローバル法令遵守要件について尋ねるには？
  
• 暗号化、トークン化、認証に関して、ベンダーに何を要求すべきでしょうか？
  
• モバイルおよびアプリ内決済のセキュリティ要件を RFP に含めるにはどうすればよいですか？
  
• 決済 RFP では、どのようなレポーティングや監査機能をリクエストすべきでしょうか？
  
• ベンダーの RFP 回答に見られる、セキュリティや法令遵守の弱さを示唆する警告サインとは？
  
• Stripe Payments の利点
  

すべての決済 RFP に含めるべきセキュリティ要件と法令遵守要件とは？

決済に関する RFP を作成する際、セキュリティと法令遵守のセクションは、すべての真剣なベンダーが満たすべき基本的な期待を定義する場所です。RFP では、ベンダーに対して、これらすべての領域にわたって、独立機関による検証を経た強固なセキュリティを実証するよう求める必要があります。

ここでは、常に含めるべき要件を紹介します。

業界認証と監査

ベンダーには、認証や監査の証明を提示するよう求めてください。カードデータについては PCI DSS (Payment Card Industry Data Security Standard)、情報セキュリティについては ISO/IEC 27001、運用管理については SOC 2 Type II を取得していること。これらの認証は、外部監査人がベンダーの業務を調査したことを証明するものです。

PCI DSS 準拠

サービスプロバイダーに関連する最高レベル (レベル 1) で PCI DSS に準拠していることを要求します。正式な証明として、認定セキュリティ評価機関 (QSA) による現在の準拠証明 (AOC) の提出を求めます。

データ保護とプライバシー

個人情報、請求先住所、個人識別情報など、すべての顧客情報をどのように保護しているかをベンダーに尋ねてください。データが地理的にどこに保存されているのか、どのように暗号化されているのか、アクセスはどのように制御されているのかを尋ねてください。データ処理契約を締結し、GDPRやCCPAなどのプライバシー法に対応していることを確認しましょう。

不正利用防止

不正利用防止の機能についても質問してください。機械学習、ルールエンジン、3D セキュア認証を使用しているか？不正利用の防止と高い承認率の維持のバランスをどのように取っていますか？RFP の回答は、正当な顧客をイライラさせることなく、チャージバックや不正利用による損失を削減できることを確信させるものでなければなりません。

インシデント対応と災害復旧

どのベンダーも、侵害や障害に対するプランを持っているはずです。インシデントをどのように検出し、対応するのか、データが巻き込まれた場合にどの程度迅速に通知してくれるのか、主要なデータ復旧目標 (RTO または RPO) はどの程度なのかを尋ねてください。

グローバル法令遵守対応

国際的に事業を展開する場合、プロバイダーは各地域の規制に対応する必要があります。PSD2、ヨーロッパでの強力な顧客認証、アメリカでの制裁スクリーニング、インドなどの国々でのデータローカリゼーションルールについて尋ねてください。グローバルベンダーは、これらの要件をカバーする具体的なシステムやライセンスを示すことができるはずです。

コアデータセキュリティ管理

暗号化、トークン化、認証に対する期待を明確にすること。データは最新の標準で転送中と静止時に暗号化し、機密データは直接触れることのないようトークン化し、ベンダーシステムは社内ユーザーに対して強力な認証を実施する必要があります。

モバイルおよびアプリ内決済

モバイルでビジネスを展開している場合は、その環境に特化した要件を含めます。ソフトウェア開発キット (SDK) のセキュリティ、PCI スコープを減らすために機密データがサーバーをバイパスするかどうか、Apple Payや Google Pay などのデジタルウォレットにどのように対応しているかなどを尋ねてください。

レポーティングと監査可能性

ベンダーは、取引レポート、不正利用および不審請求の申し立てに関する分析、管理アクションを追跡するシステム監査ログを提供する必要があります。自社で監査を実施し、法令遵守の義務を果たせるよう、データへの十分なアクセスが必要です。

PCI DSS 要件を決済 RFP に書き込むにはどうすればよいですか？

PCI DSS はクレジットカードデータに関する世界的なルールブックです。RFP では、PCI DSS 準拠を契約条項のように記載する必要があります。レベル 1 の認定を証明付きで要求し、標準の進化に合わせて準拠を維持することを確約してください。

ここでは、RFP の文言に混乱や解釈の余地を残さないようにする方法を説明します。

レベルと証明について明確に

ベンダーは PCI DSS サービスプロバイダーレベル 1 に準拠している必要があることを明記してください。これは、ベンダーが適切なレベルで業務を行っていることを証明するゴールドスタンダードです。

継続的な法令遵守の要求

PCI DSS 要件は進化し続けています。RFP では、ベンダーが最新状態を維持する方法を次のように尋ねます。「契約期間中、PCI 準拠を維持することを確認し、PCI DSS の新バージョンに適応する方法を説明してください。」回答では、年次監査、四半期ごとのスキャン、および継続的な監視について言及する必要があります。

責任分担の明確化

PCI DSS 準拠のプロバイダーであっても、一部の PCI 義務はまだ残っています。RFP で次のように明記してください。「どの PCI DSS 要件が依然として当社の責任であり、それらの要件を満たすためにどのようにサポートしてくれますか？」PCI 自己評価アンケート (SAQ) を事前に入力したり、詳細なガイダンスを提供したりするなど、負担を軽減してくれるベンダーを探しましょう。

ベンダーに質問すべきデータ保護とプライバシーの基本的な質問とは？

名前、住所、メール、デバイス ID もすべて機密情報です。適切なベンダーであれば、顧客のデータがどこに保存されるか、その保護方法、保管期間、何か問題が発生した場合の対応などを正確に伝えることができます。

これらは、確認する価値のある質問です。

データはどこで保管・処理されますか？

管轄区域は重要です。顧客データが保存される国を特定し、地域別ホスティングオプションを提供しているかどうかをベンダーに尋ねてください。透明性のある回答であれば、保存場所を明示し、適用される法的枠組みを説明し、国境を越えたデータ転送がどのように処理されるかを説明します。

個人データはどのように保護されますか？

暗号化、アクセス制御、監視などがすぐに出てくるはずです。具体的な方法について尋ねてください。保存中のデータには AES-256、転送中のデータには TLS 1.2+、最小特権の原則に基づく役割ベースのアクセスなどです。監査ログの詳細を求めてください。誰が、いつ、何の目的で、どのレコードにアクセスしたかです。すべてのタッチポイントが監視されていることの証明が必要です。

どの個人情報保護法に準拠し、どのような契約がそれを裏付けていますか？

ベンダーは、GDPR、CCPA、およびその他の関連法について明示する必要があります。RFP は GDPR に準拠したデータ処理契約書と、アクセスや削除などデータ主体の権利をどのように扱うかの証拠を要求すべきです。ベンダーが認定資格を保持しているか、認知されたフレームワークに参加している場合は、評価に含める価値があります。

保存と削除のポリシーについて教えてください。

取引データおよび個人データの保存期間と、削除または匿名化するためのプロセスを尋ねてください。構造化されたポリシーを確認してください。具体的な保存期間、自動消去、削除要求への迅速な対応能力です。

サブプロセッサーはどのような企業で、どのように審査されていますか？

ベンダーがクラウドプロバイダーやサードパーティに依存している場合は、それらが誰であるかを開示し、それらのパートナーが同じ基準で管理されていることを証明する必要があります。強力な回答は、デューデリジェンス、契約上の義務、サブプロセッサーの認証について説明します。

違反通知プロセスとは何ですか？

インシデント報告に関する書面のポリシーをリクエストしてください。タイムライン (侵害が発生してから何時間以内に報告されるか) と、どのような詳細を共有するかについて尋ねてください。最適な回答には、連絡経路やインシデント発生後の報告、改善策などが含まれます。

RFP でベンダーの不正利用防止を評価するには？

不正利用が 1% でも漏れると、収益の減少と顧客の信頼失墜を招きます。正当な取引をブロックする誤検知は、売上を損失させる可能性があります。不正利用防止というテーマでは、強力なベンダーは、何十億ものデータポイントに基づいて調整された機械学習モデル、設定可能なダッシュボード、具体的な不正率、組み込みの認証フローなど、具体的な話をします。ベンダーは不正利用防止とコンバージョンのバランスを認識し、それをどのように管理するかを示します。

確認すべき点は以下の通りです。

不正利用検知システム

不正利用検知システムの詳細をベンダーに説明してもらいましょう。大規模なデータセットで学習した機械学習、設定可能なルール、デバイスフィンガープリント、ベロシティチェック、行動シグナルなど、重層的なアプローチを探しましょう。最良のプロバイダーは、自動スコアリングと手動レビューおよびフィードバックループのオプションを組み合わせています。コンソーシアムデータ (多くのビジネスで収集されたシグナル) について言及している場合は、自社の取引だけでなく、幅広い分野からモデルが学習している証拠です。

強力な顧客認証 (SCA)

不正利用対策は、認証に直接結びつきます。3D セキュア、ワンタイムパスコード、バイオメトリックチェックなどの方法にどのように対応しているかを説明するようベンダーに求めてください。欧州で事業を展開する企業にとって、これは PSD2 の要件です。欧州以外でも、リスクの高い取引や疑わしい取引では、段階的な認証を利用できることが重要です。このようなフローを、自社で構築することなく実現できるベンダーが必要です。

追跡指標

不正利用率、チャージバック比率、誤検知率、承認率などの指標を求めましょう。高い承認率と低い不正利用率、最小限の摩擦といったトレードオフを明確にできるプロバイダーを探しているはずです。チャージバック保証や責任転嫁プログラムを提供している場合は、そのシステムに対する信頼の証ですが、それでも、どのようにしてその結果を得ているのかを理解する必要があります。

カスタマイズ能力

ビジネスにはそれぞれリスク許容度があります。不審請求の申し立てを受けても最大限のコンバージョンを求める企業もいれば、不正利用を減らすためにより多くの顧客にチャレンジする企業もいます。不正利用ルールのカスタマイズ、リスク閾値の調整、特定のシナリオのホワイトリスト化またはブラックリスト化が可能かどうかを確認してください。強力なベンダーはダッシュボードを提供し、「新規顧客からの $5,000 以上の取引にフラグを立てる」「特定の国からの初回注文はすべて 3D セキュアを必須にする」といったルールを作成できます。この柔軟性は成熟の証です。

決済手段間の保護

リアルタイム決済、デジタルウォレット、後払いなど、不正利用はあらゆるところで発生しています。RFP では、ベンダーがこれらの手段をどのように監視しているかを確認する必要があります。銀行口座の確認、受取人を制裁リストと照合するスクリーニング、アカウント乗っ取りの検出などを行っていますか？クレジットカードの不正利用についてしか説明しないベンダーの場合、他の部分で脆弱性が生じる可能性があります。

不審請求の申し立て処理

不正利用防止と不審請求の申し立て管理は密接な関係にあります。ベンダーがチャージバック対応をどのようにサポートしているか聞いてみましょう。自動的に証拠をまとめたり、不審請求の申し立てアラートを出したり、根本原因に関する分析を提供していますか？どんなに優れたシステムでもすべてを把握できるわけではないので、不正利用が発生した場合の影響を抑える能力も重要です。

ベンダーが提供すべきインシデント対応と災害復旧の詳細は？

ベンダーが侵害や機能停止にどのように備えるかで、その成熟度がわかります。適切な回答には、テスト済みのインシデント対応プラン、迅速な侵害通知、測定可能な復旧目標、回復力を高めるために構築されたインフラストラクチャー、そして常に情報を共有できるコミュニケーションプロトコルが含まれます。タイムライン、測定基準、およびテスト頻度は、準備態勢のシグナルです。

ここで知っておきたいことがあります。

インシデント対応計画

ベンダーに、セキュリティインシデントに対処するためのプレイブックを提示するよう求めてください。強力な回答は、検知、封じ込め、調査、復旧を網羅した正式なプランに言及しているでしょう。優れたベンダーは、これらのプランを定期的な訓練や卓上演習でテストし、実際のインシデント発生後に更新しています。求めたいのは、チームが実践してきたプロセスを持つパートナーです。

違反時のコミュニケーション

具体的に確認してください。「侵害が確認された場合、何時間以内に通知してくれますか？どのような詳細を提供しますか？」強力なプロバイダーは、明確な期限 (24～72 時間など) を約束し、共有する情報 (範囲、影響を受けるデータ、改善策、継続的な更新など) を説明します。エスカレーションの経路と連絡先についても明確にしてください。誰が、どのくらいの頻度で、どのような経路で連絡してくるのでしょうか。イベント後の根本原因分析を共有してくれるかどうか。復旧のパートナーとして扱ってくれるベンダーが望ましいです。

災害復旧および事業継続プラン

復旧時間目標 (RTO) と復旧時点目標 (RPO) について尋ねてください。これらの指標は、システムがどれだけ早くオンラインに戻り、どれだけのデータが失われる可能性があるかを定義するものです。具体的な数値と地理的な冗長性の証拠 (複数のデータセンター、1 つのデータセンターに障害が発生した場合に引き継ぐクラウド地域など) を確認します。これらの詳細を明確に説明できないベンダーは、プランをテストしていない可能性があります。

バックアップインフラストラクチャー

バックアップ発電機、複数のインターネットプロバイダー、自動フェイルオーバー、継続的バックアップについて尋ねてください。フェイルオーバープロセスのテスト頻度についても尋ねてください。一部のプロバイダーは、障害発生後の事後報告を公開し、説明責任の透明性を示しています。このレベルの透明性は自信の表れです。

RFP でグローバル法令遵守要件について尋ねるには？

複数の市場でビジネスを展開している (または展開するプランがある) 場合、RFP では、顧客がいるあらゆる場所でベンダーが実際に法令遵守を維持できるかどうかを確認する必要があります。強力なベンダーは、法令遵守を製品の一部として扱います。PSD2 に関する自動化、具体的なプライバシー慣行、入金に組み込まれた制裁チェック、そして関心のある市場をカバーするライセンスカタログについて言及するでしょう。

ここでは、法令遵守が必要なレベルで組み込まれているかどうかを判断するために、何を尋ねる必要があるかを説明します。

PSD2 と強力な顧客認証 (SCA)

EU の PSD2 指令では、ほとんどの電子決済に強力な顧客認証が必要です。直接尋ねてください。「強力な顧客認証 (SCA) を含む PSD2 の要件をどのように扱っていますか？免除はどのように管理していますか？」信頼できるベンダーであれば、SCA 要件が必要な場合に自動的に適用され、不要なハードルを減らすために免除 (低価値、信頼できる受益者、継続決済) が最適化されていることを確認します。望ましい詳細は、これらの免除を自動化していることであり、自社でコーディングする必要がないことです。

データ保護と GDPR

個人情報保護法はあらゆる地域にまたがっています。RFP では、GDPR、CCPA、その他のデータ保護規制に準拠する方法を説明するようベンダーに求める必要があります。顧客データの保管場所、地域ごとのホスティングオプションの有無、国境を越えた転送に使用するメカニズム (EU-米国データプライバシーフレームワーク、Standard Contractual Clauses など) を尋ねてください。契約の一部として GDPR に準拠したデータ処理契約を要求します。認定、監査、またはプライバシー体制の独立した検証を示すことができるベンダーを探します。

制裁と OFAC スクリーニング

米国やその他の国では、制裁遵守が義務付けられています。制裁措置のチェックを怠ると、罰金や風評被害にさらされる可能性があります。次のように尋ねてください。「どのような制裁スクリーニングを行っていますか (OFAC、EU、国連、その他のリスト)？制限された取引をどのようにブロックしたり、フラグを立てたりしていますか？どのリストをチェックし、どれくらいの頻度で更新しているかなど、制裁スクリーニングプロセスについて説明してください。」強力な回答は、取引および入金レベルでの自動スクリーニング、継続的なリストの更新、および一致した取引の処理手順について説明しています。

地域規制とローカライゼーション

地域によって独自のルールがあるため、RFP でカバーされていることを確認する必要があります。ベンダーに次のように尋ねてください。「どの地域の法令遵守義務に直接対応していますか？それらの要件を満たすためにどのようにサポートしてくれますか？」最適な回答は、地域ごとの規則を積極的にトラックしていることを示すものです。

ライセンスおよび規制監督

ベンダーが主要な市場で適切なライセンスまたは登録を取得しているかどうかを調査してください。これによって、規制上の責任を誰が負うのかが決まり、決済が滞りなく行われるかどうかが決まります。ベンダーには、保有している規制当局のライセンスと、その対象地域をリストアップしてもらいましょう。

暗号化、トークン化、認証に関して、ベンダーに何を要求すべきでしょうか？

もし決済ベンダーがどのように暗号化、トークン化、アクセス制御を行っているかを説明できなければ、そのベンダーの提案書を読み続ける必要はありません。具体的には、暗号化標準の名前、トークン化フローの説明、シングルサインオン (SSO) と多要素認証 (MFA) の詳細、API(アプリケーションプログラミングインターフェース)キーのロックダウン、Webhook 署名などです。

以下は、RFP が明確に取り上げるべき機能です。

暗号化

決済データの送信時および保存時のエンドツーエンド暗号化を義務付けます。明確に記述してください。移動中のデータには TLS 1.2+ または TLS 1.3、静止時のデータには AES-256 または同等のものを使用。ベンダーにキー管理方法を説明してもらいましょう。ハードウェアセキュリティモジュールを使用しているか、決められたスケジュールでキーをローテーションしているか、職務分離でキーを保護しているかなどです。暗号化は、その背後にあるキー管理によってのみ強固なものとなります。

トークン化

トークン化は、生のクレジットカード番号を環境から取り除き、ベンダーのシステムだけが解決できるランダムなトークンに置き換えます。これを要件とします。「カード保有者データはトークン化され、当社のシステムが生のデータを見たり保存したりすることはありません。」保管庫のセキュリティはどうなっているか、トークンは継続課金、サブスクリプションまたは返金に再利用できるかどうかを尋ねてください。

認証とアクセス制御

ベンダーに、自社のプラットフォームと API へのアクセスをどのように保護しているかを説明してもらいましょう。ダッシュボードへの管理者アクセスには多要素認証が必須であり、企業 ID プロバイダーとのシングルサインオン統合があればなお良いでしょう。役割ベースのアクセスと監査証跡の詳細を求めてください。異なるチームメンバーに異なるレベルのアクセスを割り当てることができ、誰がいつ何をしたかを追跡できるかです。API については、スコープされたキー、エフェメラルトークン、Webhook 署名など、認可されたシステムのみが通信を行うことを保証するコントロールを確認します。

顧客向け認証

不正利用防止はしばしば認証に関連します。ベンダーは、3D セキュア認証、デジタルウォレットでの生体認証、その他取引にリスクがあると思われる場合や規制で要求される場合の段階的チェックにどのように対応しているかを説明する必要があります。

モバイルおよびアプリ内決済のセキュリティ要件を RFP に含めるにはどうすればよいですか？

RFP では、ベンダーのモバイル統合が Web や POS 環境と同様にカードデータを厳格に保護していることを示す必要があります。これには、SDK でのカードデータの流れに関する詳細、機密情報がアプリに触れることがないことの保証、組み込みウォレットの対応、積極的なセキュリティテストの証拠などが含まれます。モバイル決済は他のチャネルと同様に安全ですが、ベンダーの統合がそれを念頭に設計されている場合に限ります。

ここでは、RFP でどこに重点を置いて質問すべきかを説明します。

PCI 準拠の SDK

ベンダーの iOS および Android SDK が PCI DSS 準拠を検証済みかどうかを確認してください。強力な SDK は、生のクレジットカードデータをアプリに触れることなく、デバイス上で暗号化してプロバイダーの安全なサーバーに直接送信し、トークンだけを返します。

ウォレットとプラットフォーム対応

デジタルウォレット (Apple Pay、Google Pay、Samsung Pay など) は、最も安全な決済手段です。ベンダーには、これらにネイティブに対応し、デバイス上で生成されたトークンがどのようにシステムを流れるかを説明するよう求めてください。優れたベンダーは、実際のクレジットカード番号が顧客のデバイスから離れることはなく、生体認証はウォレット自体で処理されることを強調します。

デバイスとアプリの保護

SDK が危険な環境をどのように扱うか尋ねてください。ジェイルブレイクやルート化されたデバイスを検出し、機密データがログに記録されるのを防ぎ、携帯電話に保存されたキーを保護しますか？適切な回答は、証明書のピン留め、制限されたストレージ、安全でない状況での決済をブロックするランタイムチェックなどのセーフガードについて説明します。

アップデートとテスト

モバイルエコシステムは急速に進化します。ベンダーには、SDK のセキュリティパッチの更新頻度や、脆弱性のテスト方法について説明するよう求めてください。定期的な侵入テストの実施や、iOS や Android の新バージョンがリリースされた際にアップデートを公開することを約束しているかどうかを確認してください。

決済 RFP では、どのようなレポーティングや監査機能をリクエストすべきでしょうか？

レポートツールと監査ツールは、財務、セキュリティ、および法令遵守チームが統制が機能していることを証明し、資金を照合し、規制当局から厳しい質問を受けたときに対応する方法です。レポーティングに真剣に取り組んでいるベンダーは、ダッシュボード、API、カスタマイズ可能なレポート、監査証跡、法令遵守の認証、およびアラートについて、保存期間、フォーマット、および統合に関する具体的な内容で説明します。RFP は、ベンダーが本当の可視性を提供するのか、それとも自力で物事をつなぎ合わせる必要があるのかを明らかにするものです。

ここでは、さらに詳しく知りたい機能をご紹介します。

取引および財務報告

取引、入金処理、返金、不審請求の申し立て、手数料について、どのようなレポートが利用できるかを尋ねてください。リアルタイムのダッシュボードや、詳細なデータを自社のシステムに取り込み可能な API を探しましょう。フォーマットや、日付範囲、地域、決済手段などのフィルターでレポートをカスタマイズできるかどうかも確認しましょう。財務チームが銀行預金と入金を簡単に照合することができない場合、下流のすべてが難しくなります。

システムアクティビティの監査ログ

成熟したプラットフォームは、ログイン、権限の変更、API キーの生成、返金の発行、設定の更新など、あらゆる機密性の高いアクションを追跡します。システムイベントとユーザーアクティビティの両方について、ベンダーが詳細な監査ログを提供することを要件に含めてください。ログが保持される期間と、ログが不変であるかどうかを尋ねてください。誰がいつ何をしたかを正確に追跡できることは、内部監査や疑わしい活動の調査に直面したときに必須です。

外部法令遵守監査のサポート

自社の監査人は、決済プロバイダーが主張通りのことを行っている証拠を求める可能性があります。ベンダーに、どのような文書 (SOC 1、SOC 2、ISO 認証、PCI DSS 証明書など) を提供しているか、またそれらのレポートをどのように共有しているかを説明してもらいましょう。NDA の下で提供するところもあれば、カスタマーポータルを用意しているところもあります。

リアルタイムの監視とアラート

チャージバック率の急増、決済拒否の異常な集中、API エラー率の上昇傾向など、異常事態をリアルタイムで通知する設定可能なアラートまたは Webhook がベンダーにあるかどうかを確認してください。早期警告システムがなければチームは迅速に対応できず、RFP は本番メトリクスの可視化が必須であることを明確にする必要があります。

データアクセスと保存期間

取引履歴や監査証跡は、金融規制当局を満足させるために何年も保存する必要があることがよくあります。次のように尋ねてください。「レポートや監査ログの保存期間は？自社の法令遵守要件のためにエクスポートしてアーカイブできますか？」強力な回答は、データをエクスポートしたり、自社のデータウェアハウスに同期したりする簡単な方法とともに、複数年の保存を約束するものです。

ベンダーの RFP 回答に見られる、セキュリティや法令遵守の弱さを示唆する警告サインとは？

RFP は、書かれていることを評価するのと同様に、何が欠けているかを見抜くことでもあります。強力なプロバイダーは、具体性と証拠に裏打ちされた明確な回答をします。それ以下であれば、前進する前に立ち止まってより深く調査する理由となります。

RFP を評価する際に注意すべき主な警告サインを以下に示します。

曖昧な表現

回答が実際の標準、プロトコル、または認証の名前を挙げずに「最先端のセキュリティ」などのフレーズに頼っている場合は、そのベンダーが詳細を提供できないか、提供しようとしないことを示すシグナルです。真剣なプロバイダーであれば、PCI DSS、SOC 2、ISO 27001、具体的な暗号化方法、具体的なプロセスについて言及します。

独立した検証の欠如

決済を処理するベンダーは外部監査を受ける必要があります。PCI DSS 認証を取得していない、または SOC レポートや ISO レポートを提供できない場合は、それらの認証を取得しているベンダーを探してください。

不明確なインシデント対応プラン

RFP では、情報漏えいの通知と文書化された復旧計画について、具体的なタイムフレームとテスト済みのプランを提示する必要があります。ベンダーが「適宜顧客に通知します」とはぐらかすなら、最も重要なときにタイムリーなコミュニケーションが保証されません。

責任転嫁

重要な義務を顧客のチームに押し付けるような対応 (「ツールは提供するが、法令遵守は加盟店の仕事だ」など) に注意してください。常に責任は伴いますが、強力なベンダーはその責任を分担し、明確なサポートを提供してくれます。

時代遅れの慣行

脆弱または旧式の標準 (パスワードハッシュの MD5 や古い PCI バージョンなど) への言及は、セキュリティが追いついていないことを示します。最新の暗号化、管理者アクセス用の MFA、最新の PCI DSS への準拠を期待すべきです。

矛盾や過剰な約束

回答内容に一貫性がない場合 (データの保存はないと主張しておきながら、保存時は暗号化しているなど) は、ずさんさや社内のコミュニケーション不足を示唆します。「不正利用ゼロ」や「稼働時間 100%」という証拠のない保証も同様に疑わしいものです。

Stripe Payments の利点

Stripe Paymentsは、成長中のスタートアップから大企業まで、あらゆるビジネスがオンライン、対面、世界各地で決済を導入するのを支援する統合グローバル決済ソリューションを提供します。

Stripe Payments で実現できることは以下のとおりです。

• 決済体験の最適化: 構築済みの決済 UI、125 種類以上の決済手段へのアクセス、Stripe が構築したウォレットである Link により、スムーズな顧客体験を実現し、エンジニアリングの工数を何千時間単位で節約できます。
  
• 新市場への迅速な展開: 195 カ国、135 以上の通貨で利用可能な国際決済オプションにより、世界中の顧客にリーチし、多通貨管理の複雑性とコストを軽減できます。
  
• 対面とオンライン決済の統合: オンラインと対面チャネルにまたがるユニファイドコマース体験を構築し、インタラクションをパーソナライズし、ロイヤルティに報い、収入を伸ばします。
  
• 決済パフォーマンスの向上: ノーコードの不正利用防止機能や承認率向上のための高度な機能を含む、カスタマイズ可能で設定が簡単な各種決済ツールにより、収益を増加させます。
  
• 柔軟で信頼性の高いプラットフォームによる迅速な成長:99.999% の過去の稼働率と業界トップクラスの信頼性を備え、スケールに合わせて拡張可能なプラットフォーム上で構築できます。
  

Stripe Paymentsでオンラインおよび対面の決済を強化する方法について詳しく確認してください。または本日から利用を開始することもできます。