支払いデータのインポートをリクエストする

Stripe は、顧客がお客様のサイトに留まったまま支払いを完了できるように、お客様のセキュリティ要件を簡素化します。これは、クライアント側とサーバー側のステップの組み合わせで実現されます。

1. 顧客のブラウザーで実行されているウェブサイトから、Stripe によって支払い詳細が安全に収集されます。
2. Stripe が、代表のトークンで応答します。
3. ブラウザーからフォームの他のデータとともに、トークンがサーバーに送信されます。
4. サーバー側のコードは API リクエスト (支払いの作成時など) でそのトークンを使用します

このアプローチは、機密の支払い情報をお客様のサーバに保存することなく、Web サイトのチェックアウトフローを合理化します。これにより、PCI コンプライアンス規制に従って運用できるため、時間を節約し、経済的メリットを得られます。

Stripe での決済処理フロー

他の決済代行業者と比べて、Stripe の組み込みは以下の点で異なります。

• 顧客がウェブサイトを離れることはありません。
• トークン作成が特定の商品や金額に紐づけられません。
• オンデマンドでクライアント側のキーを作成する必要はありません (代わりに設定された公開可能な API キーを使用します)。

組み込みを準備する

すべての新しい顧客トークン (インポートされていない) に対して、以下を実装します。

• Customer オブジェクトを使用してカード情報を保存します。
• Collect and tokenize customer card information with one of our recommended payments integrations.
• これらの新しい顧客の支払いを作成します。

このアプローチを使用すると、移行プロセス中に既存の決済代行業者の現在の顧客に影響を及ぼさずに、Stripe で新しい顧客からの支払いを受け付けることができます。

導入に関する考慮事項

インポートされたデータを処理する最も効率的な方法は、決済代行業者に Stripe へのデータ転送を依頼する前に組み込みを設計することです。インポートをリクエストする前に実行できる対応は、次のとおりです。

• Stripe アカウントの設定を完了する。
• 顧客レコードを再マッピングします。
• 移行中の支払い情報の更新を処理します。
• Adaptive Acceptance、自動カード更新機能 (CAU)、ネットワークトークンなどのすべての最適化を有効にします。

顧客レコードの再マッピング

必要に応じて、以前のレコードの支払い方法データを既存の Stripe 顧客オブジェクトにインポートするように統合を設定できます。これにより、移行によって、以前の決済代行業者から受信したファイル内の一意の顧客 ID ごとに、Stripe アカウントに新しい (重複する可能性のある) 顧客が作成されるのを防ぐことができます。

移行後、次の場合には、新しい Stripe Customer 識別子に対応するように一部のレコードを更新する必要がある場合があります。

• 移行前に Stripe 顧客を作成し、その後支払い情報をインポートしてこの顧客レコードを更新しました。
• 支払い情報を新しい顧客レコードとしてインポートしました。

たとえば、顧客 jenny.rosen@example.com の ID は、データベースでは 42 で、以前の決済代行業者のシステムでは ID 1893 に対応していますが、Stripe アカウントでは ID cus_12345 です。この場合、データベースで ID 42 を Stripe ID cus_12345 にマッピングする必要があります。Stripe は、必要な再マッピングを識別するのに役立つ、インポート後のマッピングファイルを提供します。

支払い情報の更新を処理する

データの転送からインポートの完了までの間に、顧客が以前の決済代行業者で支払い情報を更新した場合、その変更は失われます。

保存された支払いの更新を処理するサイトのプロセスを更新して、顧客に対するエラーや請求の問題を防止します。これには、Stripe 顧客 ID が保存されていない顧客について、ご自身で移行を実行するための以下の準備が含まれます。

1. Stripe で顧客用の新しい Customer オブジェクトを作成します。
2. Customer オブジェクトに支払い方法を関連付けます。
3. 必要に応じて、サブスクリプションを移行します。

移行が完了すると、有効期限の変更など、Stripe はカードによってトリガーされる更新を自動的に処理します。

1. 組み込みを完了し、Stripe で支払いを処理する準備が整ったら、以前の決済代行業者に支払いデータをリクエストします。多くの決済代行業者では、アカウント所有者がデータ転送をリクエストする必要があります。
2. Stripe アカウントにログインして、移行リクエストフォーム を送信し、インポート移行をリクエストしてください。
3. 移行リクエストの受信後に作成される認証済みのメールスレッドを通じて、Stripe とやり取りします。

Stripe では、顧客の請求先住所情報と支払いの詳細をインポートできます。特定の支払いタイプの移行の詳細については、以下を参照してください。

• カード
• ACH
• SEPA
• Bacs
• PADs/ACSS

データ移行ではサブスクリプションは移行されませんが、サブスクリプションを個別に再作成したり、Billing 移行ツールキットを使用してインポートしたりすることができます。

以前の決済代行業者が最終データを Stripe に転送するまでに数日または数週間かかる場合があります。移行の計画では、この移行時間を考慮してください。

以前の決済代行業者がデータを転送した後、Stripe はデータを確認し、インポートに関する問題を特定します。Stripe はお客様と以前の決済代行業者と連携して問題を修正します。その後、インポートの概要を共有し、最終的な確認と承認を行います。

承認されたら、Stripe はそのデータをお客様のアカウントにインポートします。転送されたデータファイルにある一意の各顧客に対して Customer オブジェクトを作成し、顧客のカードを Card オブジェクトまたはPayment Method オブジェクトとして作成して関連付けます。転送されたデータで顧客のデフォルトのカードが指定されている場合には、Stripe はそれを、顧客の支払いとサブスクリプションのデフォルトの支払い方法として設定します。

移行時までに Stripe アカウントに大量の顧客レコードが蓄積されている場合は、新しい Customer オブジェクトを作成する代わりに、インポート日付を既存の Stripe 顧客オブジェクトにマッピングすることを検討してください。

Stripe では通常、以前の決済代行業者から正しいデータを受け取ってから 10 営業日以内に、Stripe チームとの共有を希望される補足データファイルとともにデータをインポートします。

インポートが完了すると、Stripe から、現在の決済代行業者の ID とインポートされた Stripe オブジェクト ID 間のマッピングされた関係を示す CSV ファイルまたは JSON ファイルの選択肢が送信されます。このマッピングファイルを解析し、それに従ってデータベースを更新します。移行中に行われた カードの更新が実装によって処理されていることを確認してください。

インポート後のマッピングファイル

このマッピングファイルで組み込みを更新すると、Stripe ですべての顧客への請求を開始できます。

{
  "1893": {
    "cards": {
      "2600": {
        "id": "card_2222222222",
        "fingerprint": "x9yW1WE4nLvl6zjg",
        "last4": "4242",
        "exp_month": 1,
        "exp_year": 2020,
        "brand": "Visa"
      },
      "3520": {
        "id": "card_3333333333",
        "fingerprint": "nZnMWbJBurX3VHIN",
        "last4": "0341",
        "exp_month": 6,
        "exp_year": 2021,
        "brand": "Mastercard"
      }
    },
    "id": "cus_abc123def456"
  }
}

上記の JSON マッピングの例は、次のようになります。

• 顧客 ID 1893 を ID cus_abc123def456 の新しい Stripe 顧客としてインポートしました。
• 顧客カード ID 2600 を ID card_2222222222 の新しい Stripe カードとしてインポートしました。
• 顧客カード ID 3520 を ID card_3333333333 の新しい Stripe カードとしてインポートしました。

移行リクエストで指定すると、Stripe はカード データを Card オブジェクトではなく PaymentMethods としてインポートできます。次の例は、さまざまな種類の支払い情報のインポートのマッピングファイルを示しています。

old_customer_id,customer_id,old_card_id,card_id,card_fingerprint,card_last4,card_exp_month,card_exp_year,card_brand
old_cus_100,cus_abc123def456,old_src_100,card_2222222222,x9yW1WE4nLvl6zjg,424242,09,2024,Visa

インポート後の支払い拒否

移行後は、支払いのパフォーマンスを監視して、インポートされた支払いデータの承認率が想定どおりであることを確認します。

決済の受け付け (またはカード発行会社オーソリ成功率) は、支払いのために送信されたすべての取引のうち、カード発行会社が正常に承認した取引の割合です。この指標には、承認のために送信されることのないブロックされた取引 (Radar ルールなどによる) は含まれません。

一般的なアプローチと移行後の両方で、支払いのオーソリの最適化の目標を事業目標に合わせます。たとえば、単価の低いデジタル商品ビジネスでは、リスクレベルを設定して、ブロックする支払いの数を減らすことができます。潜在的な影響を考慮してください。

• ユーザーの負担を減らすことで、コンバージョン率が向上します。
• リスクの高い支払いが実行されることにより、詐欺の被害に遭う可能性が高まります。
• 発行者による不正モデルブロックにより、発行者の未対応のオーソリ率が低下します。

正確なデータ (カード保有者名、請求先住所、メールアドレスなど) を提供するようにしてください。カード保有者の_意図_を反映することで、オーソリが成功する可能性が最大限に高まります。

登録済みのカードで本人確認を行う

支払いデータの移行には、登録済みのカード (同じ顧客に対する今後の 加盟店が開始した支払いまたはオフセッション 支払いのために保存されたカード) が関係します。インポートした支払いデータを保存し、正しい off_session パラメーターを使用して登録済みのカードを使用した支払いにラベルを付けるようにしてください。登録済みのカードで正しく本人確認を行えない場合は、次のようになります。

• 今後の支払いや定期的な支払いに対するカード保有者の同意を確認できない発行者は、支払いを拒否する可能性があります。
• 支払いデータは、自動カード更新機能 (CAU) やネットワークトークン (NT) などの特定の Stripe 最適化製品では対象外となる可能性があります。

最適化の機会を特定するために拒否の理由を確認する

移行後に、発行者の拒否の理由は、移行された支払いデータが想定どおりに処理されているかどうかを確認するのに役立ちます。特定の種類の拒否の急増には、次の最適化製品が役立つ場合があります。

• Card account updater: Stripe’s partnerships with card networks allows us to automatically obtain updates for expired or replaced cards in both real-time and the background.
• 自動再試行 (督促): 多数のカードの再試行 (移行後など) は、カード発行者に疑わしい印象を与える可能性があるため、注意してください。請求の支払いに Stripe の Smart Retries を使用すると、機械学習モデルが拒否コード、支払い方法の更新、銀行のリスクしきい値アクティビティを分析し、経常収益の支払いをより戦略的に再試行します。
• ネットワークトークン: 特定の支払い口座番号 (PAN) をカードネットワークの安全なトークンに置き換えて、PAN の更新 (更新や交換など) がトークンに自動的に反映されるようにします。
• Adaptive Acceptance: Stripe は機械学習を使用して、オーソリリクエストに対する小さな調整 (フォーマットなど) の効果をリアルタイムで評価し、顧客に元の拒否を返す前に支払いの再試行を調整します。
• Customer outreach: Asking your customer to log in and re-enter or re-verify their payment details often re-establishes your business’s trustworthiness with the customer and the payment providers. Consider notifying customers through channels other than email, such as text messages or in-app notifications.

次の表は、さまざまな拒否の理由に対して、どの最適化製品で改善できるかを示しています。

PGP に詳しくない場合は、GPG をご覧いただき、公開キーのインポートから始めてください。PGP の基本を理解したら、次の PGP キーを使用して、 PCI 準拠の移行用に機密データ (クレジットカード情報など) を暗号化します。

これにより、次の情報を含む FILENAME.gpg が作成されます。

• キー ID: 9C78B7620C1E99AD
• キータイプ: RSA
• キーサイズ: 4096 bits
• フィンガープリント: AEBF 7C48 38C4 4D2F DC99 A3F9 9C78 B762 0C1E 99AD
• ユーザー ID: Stripe Import Key (PCI) <support-migrations@stripe.com>

キーをインポートした後、コマンドラインプロンプトで次のコマンドを実行して、送信するファイルを暗号化することができます。

gpg --encrypt --recipient 9C78B7620C1E99AD FILENAME

暗号化されたデータを Stripe に提供する詳細については、補足データのアップロード を参照してください。