カードデータをインポートする

以前の決済代行業者からカードデータを移行すする場合、そのデータをデフォルトの支払い方法カード (pm_) オブジェクトまたは従来のカード (card_) オブジェクトとして Stripe にインポートできます。Payment Intents API は、両方のカード支払いタイプについてすべての Stripe 製品をサポートしていますが、導入では次の考慮事項に基づいてどちらか一方を優先する場合があります。

• Stripe でサードパーティのサブスクリプションプラットフォームを使用している場合は、プラットフォームまたは開発者に問い合わせて、どちらが適しているかを確認してください。

• Stripe アカウントに既存の支払いデータがある場合は、すでに使用しているタイプと一致するようにしてください。

  • pm_: Payment Methods API を Payment Intents API と組み合わせて使用します。
  • card_: Card API を Payment Intents API と組み合わせて使用します。
  • src_: 非推奨の Sources API を引き続き使用できますが、より多くの機能にアクセスするには Payment Intents API に移行することをお勧めします。

デフォルトのカード

デフォルトのカード は、顧客が定期支払い、サブスクリプション、または今後の取引のデフォルトの支払い方法として設定または選択する主要なカードです。カードを default としてマークすると、特に指定しない限り、そのカードは自動的に次の取引の支払い方法になります。自動定期支払いを必要とするサブスクリプションベースのサービスにこの機能を使用します。新しいカードを新しいデフォルトの支払い方法として設定したり、現在のデフォルトを変更せずに追加の支払い方法として追加したりできます。

デフォルトのカードデータを指定する

• デフォルトカード情報をデータファイルの別の列に含めます。デフォルトのカードと非デフォルトのカードを識別できるように、TRUE 値と FALSE 値を使用することをお勧めします。
• インポート時にカードをデフォルトとしてマークすると、既存の顧客の現在のデフォルトの支払い方法 (設定されている場合) が上書きされます。

現在の制限事項

Stripe は、Google や Apple などのデジタルウォレットに保存されたカードを移行できません。これらのサービス (以前の決済代行業者ではない) は、セキュリティのために保存された値をトークン化するためです。デジタルウォレットに関連付けられたカードは、Stripe の新しい支払い方法として追加する必要があります。

Stripe Tax の住所確認

Stripe Tax を使用して顧客データをアカウントに移行する場合は、次の理由から顧客住所フィールドを含めます。

• 税金計算の正確性: 住所は、さまざまな管轄区域で税金を正確に計算するのに役立ちます。
• 税法の遵守: 現地の税法では、税金請求書の正確性を保つために住所の記載が義務付けられています。
• 監査とレポート: 正確な住所データは税務監査のコンプライアンスに役立ち、取引場所を記録することで内部分析を強化します。
• 顧客の決済体験の向上: 正確な住所から開始することで、正確で自動的な税金計算が可能になり、リピーターの決済プロセスが改善されます。
• 税法の変更への適応性: 顧客の完全な住所データセットにより、企業は税法の変更に適応し、コンプライアンスの問題を防ぐことができます。

自動カード更新機能 (CAU)

決済代行業者からのファイルには有効期限切れのカードが含まれている場合が多くあります。Stripe の自動カード更新機能 (CAU) は、カード発行会社から新しいカードの詳細を取得して適用することで、保存されているカード情報を自動的に更新します。

CAU はサービスの継続性を最大化し、承認率を向上させますが、アカウント内の更新されたカードごとに料金が発生する場合があります。インポート中に期限切れのカードをどのように処理するかを指定できます。

• 期限切れのカードをスキップ: 期限切れのカードのデータをインポートしません。

  注

  CAU は有効期限が切れていないカード (盗難されたカードや交換したカードなど) を更新し、移行後の料金が発生する場合があります。

• 期限切れのカードをインポート: CAU が可能な限り多くのカードを更新し、CAU 料金をアカウントに請求できるようにします。

仕組み

強力な顧客認証 (SCA) の証拠を移行する

欧州のユーザーの場合、PSD2 (第 2 次決済サービス指令) により、電子決済のセキュリティを強化するために 強力な顧客認証 (SCA) が義務付けられています。SCA では、取引に対して 3 つの独立した認証要素のうち 2 つが要求されます。

• 顧客が知っている情報 (パスワードなど)
• 顧客の所有者 (モバイルデバイスなど)
• 顧客に関する情報 (生体認証データなど)

以前の決済代行業者からのネットワーク取引 ID は、顧客が以前のプロセッサで SCA を使用して取引を認証したことを示し、Stripe が今後の取引に対して SCA 免除を申請できるようにします。これにより、顧客にとって Stripe への移行がシームレスになり、再認証の必要がなくなります。

以前の決済代行業者が取引 ID を提供できない場合は、インポートリクエストフォームでお知らせください。代替オプションをご提供いたします。

日本の Stripe アカウント向けの 3DS 同意書

日本の改訂クレジットカード・セキュリティガイドラインでは、日本の企業に対して 2025 年 3 月末までに3D セキュア 2.0 (3DS) の導入を義務づけています。

日本のビジネスで 3DS を使用していない場合は、移行リクエストフォームの 追加情報 セクションでその旨を報告してください。デフォルトではこれは、カードが移行後の日本での 3DS 必須要件から免除されるように設定されていることを意味する、と解釈されます。

Stripe はサポートとサービスを調整して、業務やセキュリティを中断することなく業界標準に準拠できるように支援します。

詳しくは、日本における 3DS の導入の義務化についてをご覧ください。

カードファイルに関するガイダンス

• 決済代行業者はさまざまなフィールドを指定できます。
• 決済代行業者には、すべての顧客データと支払い方法データを Stripe に完全にエクスポートするよう推奨します。
• Stripe は必要に応じて、以前の決済代行業者のデータから不要なフィールドを除外できます。
• 以前の顧客 ID または以前のソース ID のいずれかが両方のファイルに存在する場合、Stripe は受信した複数のファイルを結合できます。

ファイル形式に関する要件

インポートを続行するには、エクスポートデータファイルが次のデータ標準を満たしている必要があります。

• ファイルは CSV 形式である必要があります。
• ファイルは UTF-8 でエンコードされている必要があります。
• 行は 1 つの改行文字 で区切ります (not \r )。
• 列は , で区切ります。
• カンマを含むすべてのフィールドを二重引用符 " で囲む必要があります。すべてのフィールドを二重引用符で囲むことをお勧めします。
• 空のフィールドは完全に空のままにします (区切り文字の間に文字を入力しない)。 不足しているフィールドを NULL、N/A、またはその他の値で示すことは_できません_。
• 内容に二重引用符が含まれる場合、CSV RFC に従って別の二重引用符でエスケープします。たとえば、William "Bard of Avon" Shakespeare を "William ""Bard of Avon"" Shakespeare" にフォーマットするとします。
• フィールド内に改行文字 (\r または \n) を含めることはできません (避けるべき例: 101 1st Ave\nApt 1)。
• すべての行の列数は同じである必要があります。
• 列は任意の順序に対応します。
• 機密データファイルを SFTP 経由で送信する前に、PGP キーを使用して暗号化する必要があります。

カードのデータのフィールド