オリジナルの支払いフォームを使用することが重要な理由

支払いフォームは、ユーザーが最も機密性の高いデータ（カード番号、CVC、ウォレットログイン）を入力するポイントです。フォームがオリジナルでない場合（偽サイト、プロバイダのホストフォームの代わりにマーチャントの「自己作成」カードフィールド、統合が壊れている）、データ漏洩、銀行の故障、チャージバック、ロックのリスクがあります。元のフォームは、セキュリティ認証を通過し、正しいシナリオ（iFrame/Hosted Fields/redirect）に従って接続されている支払いプロバイダ（PSP/bank）のページ/ウィジェットです。

「元の支払いフォーム」とは"

PSPによってホストされる：PAN/CVC/termフィールド-プロバイダのiFrame/Hosted Fields内またはドメイン上（リダイレクト）。

PCI DSSに対応：商人は「生の」カードデータを表示せず、トークンのみを受け取ります。

Secure 2 SCA/3-Dサポート：銀行を通じた支払いの確認（プッシュ/SMS/バイオメトリクス）。

プロトコルによって保護される：厳密なTLS、 HSTS、 CSPのクリックジャッキングの保護。

識別可能：正しいドメイン/証明書とマーチャントの詳細と予測可能なUX。

なぜ重要なのか（ユーザーとビジネス）

ユーザーのために

カードデータの保護：カードフィールドのトークン化と分離は、商人やスクリプトによる「覗き見」を除外します。

フィッシングとアカウントの盗難が少ない：受信者の名前と3-DS2が銀行への支払いを確認します。

支払いが成功する可能性が高い：正しい統合=技術的な失敗が少なくなります。

ビジネスのために

コンプライアンスとペナルティの削減：PCI DSSコンプライアンスは監査責任とコストを削減します。

より少ないチャージバック：3-DS2は論争の発行者に責任を移します。

より多くの変換：高速SCA、 Apple/Google Pay、ワンクリックで保存されたトークン。

ブランド保護：「formjacking」（悪意のあるスクリプトを埋め込む）および漏出無し。

適切な統合がどのように見えるべきか

1.マーチャントページ内のPSPまたはホストフィールド/iFrameドメインにリダイレクトします。

2.カードフィールド（PAN/CVC/expiry）は、技術的にはプロバイダに属します-商人はトークンを受け取ります。

3.SCA/3-DS 2は自動的に開始します：銀行アプリケーション、生体認証、SMSコードにプッシュします。

4.ページレベルの保護：HSTS、コンテンツセキュリティポリシー（CSP）、 X-Frame-Options、 nonce/scriptハッシュ。

5.Pure UX：単一のフォント/レイアウトまたは独自のPSPウィジェット、商人の正しい記述子。

オリジナルでないフォームが危険な理由

Formjacking （Magecart）：悪意のあるJSが即座にPAN/CVCを削除します。

フィッシング/ドメイン置換：類似のURL、偽のロゴ、「ロック」自体は何も保証しません。

PCI非準拠：罰金、必須監査、ブロック取得。

免責事項と源泉徴収：発行者はグレーの統合をカットします。

KYCリーク：「両側のフォトカード」を要求し、電子メールによるパスポートは重大な違反です。

元のフォームの機能（ユーザー用）

マップフィールドは組み込みのiFrame（小さなウィンドウの中のカーソルとフレーム）に配置されているか、よく知られているPSP/バンクのドメインにアクセスします。

アドレスバー：HTTPS、有効な証明書、タイプミスなしの正しいドメイン。

3D セキュア/SCAは自動的に表示されます（銀行からのプッシュ/SMS/生体認証）。

チャット/メールにPAN/CVC/フォトカードを送信する要求はありません。

プライバシーポリシーと支払い条件はオープンで読みやすいです。

赤い旗（すぐに停止）

iFrame/Hosted Fieldsなしでマーチャントサイト上のフィールドを直接マップします。

電子メール/メッセンジャーまたは「両側のフォトカード」でPAN/CVCをお願いします。

ドメインは奇妙です：'pay-secure。ショップブランドを確認します。ブランド/PSPドメインの代わりにnet'。

ページは、支払いステップで非シークレットリソース（http）を引っ張るか、証明書で「誓う」。

壊れたローカライズ、ピクセルロゴ、スペルエラー、「2：59」タイマーの支払い。

ユーザーのチェックリスト（1分）

支払いはPSPまたはiFrame/Hosted Fieldsにリダイレクトされます。
HTTPS/証明書は有効で、ドメインは置換されません。
SCA/3-DS2が動作しました（プッシュ/SMS/生体認証）。
チャット/メールにPAN/CVC/フォトカードを送信しません。
あなたのプライバシーポリシーと連絡先を適切に保ちます。

ビジネスチェックリスト（統合/セキュリティ）

ホストフィールド/iFrameまたはPSPリダイレクトを使用する;商人はPAN/CVCを見ない。
PCI DSS：統合型、トークン化、ネットワークセグメンテーションによるSAQ A/SAQ A-EP。
CSP/HSTS/XFOが有効になっています。外部スクリプト-hashes/nonceを持つallow-listによって。
にします。フォールバックOTP/プッシュ；ウォレットサポート（Apple/Google Pay）。
前面変更（SRI、カナリアスクリプト）の監視、フォームジャッキングに対する保護。
クリアテキスト：取得者/PSPは誰ですか、データがどのように処理されるか、日付を返します。
定期的な浸透試験と依存性制御（SCA-ソフトウェア組成分析）。

一般的な問題とそれらを迅速に解決する方法

［症状］	Reason（理由）	Decision（意思決定）
多くの「辞退/尊敬しない」	誤った統合、3-DS2の欠如	3-DS2の有効化、BINルール、ディスクリプタ、およびMCCの検証
顧客は'frods'について不平を言う'	フロントエンドのFormjacking/マルウェア	CSP/SRIを有効にし、フィールドをホストフィールド、フェーズ、キー回転に変換する
電子メールでフォトカードを求める	不適切なサポートプロセス	直ちに禁止する。PAN/CVCを使用せず、安全なKYCプロバイダを介してのみ
銀行は頻繁にSCAを要求します	リスクシグナル/新しいデバイス	オーケストレーションの設定、トークン/デバイスの保存、行動スコアリングの改善

FAQ（短い）

アドレスバーロック=セキュア？

いいえ、そうではありません。これはただの暗号化です。ドメイン、ホスト形式、3-DS2、ポリシーを見てください。

iFrameがサイトのフィールドより優れているのはなぜですか？

PAN/CVCはPSPに直接アクセスし、商人のフロントに触れないため、リスクやPCI要件が少なくなります。

電話/チャットでカードの詳細を取ることはできますか？

いいえ、そうではありません。これは総PCI違反です。ホストされたフォームで支払いリンク/請求書を使用します。

フォームがSCAなしで「ハング」した場合？

再起動し、ネットワーク/ブラウザを確認します。PSPのポップアップ/スクリプトをブロックしないようにしてください。

会社のためのミニポリシー（既製フレームワーク）

1.ホストされたフィールドのみ/PAN/CVCのリダイレクト。

2.3-DS 2/SCAはカードに必須です。Apple/Google Payで接続。

3.CSP/HSTS/XFO/SRI+strict allistドメイン。

4.スクリプト置換の前面とアラートを監視します。

5.SAQ/PCI監査毎年；ペンテストは予定通りだ。

6.サポートは決してPAN/CVC/フォトカードを要求しません；保護されたKYCチャンネルのみ。

元の支払いフォームは美学ではなく、セキュリティと合法性です。ホストフィールド、トークン化、SCAはカード所有者を保護し、コンバージョンを増やし、ビジネスからリスクのかなりの部分を削除します。ユーザー-ドメイン、フォーム、SCAをチェックします。ビジネス-堅い前部防御との証明された統合だけを使用して下さい。これらのルールに従って、データ漏洩と支払い失敗のシナリオの90％を閉じます。