请求导入支付数据

安全地导入敏感的支付数据。

Stripe 允许您在迁移到 Stripe 时保留现有客户和支付数据。我们会根据需要与您的团队及当前的支付提供商合作，通过几个步骤安全地迁移您的信息：

构建您的 Stripe 集成。
请求并确认迁移详情。
更新您的集成以完成迁移。
（可选）迁移订阅。

此过程允许您在 Stripe 上接受新客户并向其扣款，并继续使用您当前的处理商向现有客户扣款，直到迁移完成。您的客户不会发生宕机。迁移过程完成后，您可以在 Stripe 上处理所有付款。

先构建并测试您的 Stripe 集成，然后再向您当前的服务商请求数据。这样您就有充足的时间来验证和测试您的新集成。如有关于迁移过程或与 Stripe 集成的任何疑问，敬请告知。

构建您的 Stripe 集成

Stripe 简化了您的安全要求，以便您的客户无需离开您的网站即可完成付款。这是通过客户端和服务端的组合步骤完成的：

从客户浏览器上打开的您的网站，Stripe 会安全地收集客户的支付信息。
Stripe 会返回一个代表令牌作为响应。
浏览器会将令牌连同其他所有表单数据一起提交到您的服务器。
您的服务器端代码在 API 请求中使用该令牌（例如，创建收费时）。

这种方法可以简化您的网站的结账流程，同时敏感的支付信息永远不会接触到您的服务器。这使您可以按照 PCI 合规法规进行操作，从而节省时间并带来经济效益。

Stripe 的支付流程

与其他支付处理商相比，Stripe 集成在以下方面可能有所不同：

您的客户无需离开您的网站。
创建令牌时不绑定具体产品或金额。
无需按需创建客户端密钥。相反，您使用一组可发布的 API 密钥。

准备您的集成

对于所有新的客户令牌（未导入），请执行以下操作：

使用客户对象保存银行卡信息。
使用我们推荐的四种支付集成之一采集和令牌化客户的银行卡信息。
为这些新客户创建收费。

使用这种方法，您可以在 Stripe 上接受新客户的付款，而无需在迁移过程中影响现有处理商中的现有客户。

集成注意事项

在让您的支付处理商向 Stripe 传输数据之前设计您的集成是处理导入数据的最有效方式。在请求导入之前，您可以采取的一些操作包括：

完成您的 Stripe 账户设置。
重新映射客户记录。
处理迁移期间付款信息的更新。
启用所有优化功能，例如自适应接受率、银行卡账户更新器 (CAU) 和卡组织令牌。

重新映射客户记录

如果愿意，可以将您的集成配置为将支付方式数据从先前记录导入到现有 Stripe 客户对象中。这样做可以防止迁移操作在您的 Stripe 账户中为我们从您以前的处理商那里收到的文件中的每个唯一客户 ID 创建一个新的（可能是重复的）客户。

迁移后，在以下情况下，您可能仍需要更新一些记录以与新的 Stripe Customer 标识符对应：

您在迁移前创建了 Stripe 客户，然后我们导入了支付信息来更新此客户记录。
我们以新的客户记录导入了支付信息。

例如，客户 jenny.rosen@example.com 数据库中的 ID 可能为 42，在您先前处理商的系统中对应于 ID 1893，但在您的 Stripe 账户中为 cus_12345。在这种情况下，您现在必须将您的 ID 42 映射到数据库中的 Stripe ID cus_12345。Stripe 提供了一个导入后映射文件来帮助您识别所需的重新映射。

处理支付信息的更新

如果客户在传输数据和完成导入之间的时间窗口内使用您先前的处理商更新其支付信息，这些更改将丢失。

更新您网站的已保存的付款更新处理流程，以防止客户出现错误或账单问题。这包括对未存储 Stripe 客户 ID 的客户进行自迁移的一系列准备：

在 Stripe 中为您的客户创建新的 Customer 对象。
将支付方式关联到 Customer 对象。
如有必要，可以迁移订阅。

迁移完成后，Stripe 会自动处理银行卡触发的更新，例如失效日期更改。

请求并确认迁移详细信息

在您完成集成并准备好在 Stripe 上处理付款后，向您之前的处理商请求您的支付数据。许多处理商要求账户所有者请求数据转移。
登录您的 Stripe 账户以提交迁移申请表，请求进行导入迁移。
通过我们在收到您的迁移请求后创建的经过身份验证的电子邮件线索与 Stripe 联系。

警告

切勿将敏感的信用卡详细信息或客户信息直接发送给 Stripe。如果您有这些数据，请在您的迁移申请表中告诉我们，以便我们帮助您安全地转移您的数据。

Stripe 可以导入您的客户账单地址信息和付款详情。了解有关迁移特定付款类型的更多信息。

数据迁移不会迁移订阅，但您可以单独重新创建订阅或用 Billing 迁移工具包导入订阅。

您之前的处理商可能需要几天或几周的时间才能将最终数据传输到 Stripe。在您的迁移计划中预留此过渡时间。

在您之前的服务商转移您的数据后，Stripe 会审查数据并识别导入过程中存在的任何问题。我们与您和您以前的处理商一起纠正任何问题。然后，我们会分享导入的摘要，供您最终审核和批准。

在您批准后，Stripe 会将数据导入您的账户。我们为转移数据文件中的每个唯一客户创建一个 Customer，并以 Card 或 Payment Method 对象创建并绑定客户的银行卡。如果转移的数据指定了客户的默认银行卡，则我们将此卡设置为客户的默认支付方式，用于收款和订阅付款。

如果您的 Stripe 账户在您迁移时已积累了大量客户记录，则考虑将导入日期映射到现有 Stripe 客户对象，而非创建新的 Customer 对象。

Stripe 通常会在收到您之前的服务商发来的正确数据后的 10 个工作日内导入数据，以及您想与我们的团队分享的任何补充数据文件。

更新您的集成

完成导入后，Stripe 会向您发送一个 CSV 或 JSON 文件，显示当前服务商的 ID 与导入的 Stripe 对象 ID 之间的映射关系。解析此映射文件并相应地更新您的数据库。确保您的集成处理了过渡期间发生的任何银行卡更新。

导入后映射文件

用此映射文件更新您的集成后，即可开始在 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 可以将其导入为 PaymentMethods 而非 Card 对象。以下示例显示了不同类型支付信息导入的映射文件。

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 规则造成的交易），因为这些交易从未提交授权。

在使用一般方法和迁移后，请使支付授权优化目标与业务目标保持一致。例如，单位成本较低的数字商品业务可以将其风险级别设置为阻止较少的付款。考虑可能的影响：

由于阻力更小，转化率更高。
由于付款风险较高，欺诈风险会增加。
由于发卡行阻止欺诈模型，原始发卡行授权率较低。

确保提供准确的数据（如持卡人姓名、账单地址和电子邮件）。反映持卡人的 intent 会尽可能提高授权成功的可能性。

识别存档的银行卡

支付数据迁移涉及 file_（为同一客户的未来商家发起或会话外付款而保存的银行卡）上的 _cards。请务必存储导入的支付数据，并用正确的 off_session 参数标记这些存档的卡付款。如果您错误地识别存档的银行卡：

如果发卡行无法确认持卡人是否同意未来付款或经常性付款，可能会拒绝。
支付数据可能不符合某些 Stripe 优化产品的条件，例如银行卡账户更新器 (CAU) 和卡组织令牌 (NT)。

监控优化机会的拒绝原因

在迁移后，您的发卡行拒绝原因可以帮助您确定迁移后的支付数据是否正常交易。某些类型的拒付激增可能受益于以下优化产品：

银行卡账户更新：Stripe 与银行卡网络保持合作，能够实时或在后台自动获取过期银行卡或已更换银行卡的更新信息。
自动重试（催款）：请谨慎操作，因为多次重试（例如在迁移后）对发卡行来说可能是可疑行为。如果您使用 Stripe 的 Smart Retries 功能，我们的 AI 模型会分析拒付代码、支付方式更新和银行风险阈值活动，以更具战略性地重试经常性收入付款。
卡组织令牌：用来自卡组织的安全令牌替换特定支付账号 (PAN)，以确保 PAN 更新（如更新或更换）自动反映在令牌中。
自适应接受率：Stripe 使用 AI 实时评估对授权请求进行细微调整（如格式化）的效果，然后优化付款重试，最后将原始拒付结果返回给客户。
客户拓展：要求您的客户登录并重新输入或重新验证其支付信息，通常可以重新建立您在客户和支付提供商心目中的信任关系。考虑通过电子邮件以外的渠道通知客户，例如短信或应用内通知。

下表显示了哪些优化产品针对各种拒付原因提供的改进。

拒付代码可能包括	迁移效果	允许的操作	不允许的操作
`incorrect_number` `invalid_number` `expired_card`	在自然迁移滞后期间更新银行卡数据可能会导致保存的银行卡数据过期。	银行卡账户更新器卡组织令牌自适应接受率联系客户	重试
`generic_decline` `do_not_honor`	更改您的对账单描述符或其他标识标记可能会触发发卡行的风险模型，或使您的客户感到困惑。	重试卡组织令牌自适应接受率联系客户	银行卡账户更新器
`transaction_not_allowed` `try_again_later` `authentication_required` `incorrect_cvc`	某些迁移的支付数据可能缺少初始银行卡验证信息，如卡组织令牌或原始交易 ID。	银行卡账户更新器重试自适应接受率联系客户	卡组织令牌
`lost_card` `stolen_card` `invalid_account` `pickup_card` `card_not_supported`	在迁移滞后期间，客户可能会报告卡丢失或被盗。请留意与这些拒付相关的特殊 CONTAC 事件。	卡组织令牌联系客户	CAU 重试¹ 自适应接受率

¹ 发卡行可能会对重试丢失或被盗的支付数据感到可疑。

可选使用订阅

涉及订阅的迁移通常包括以下阶段：

您可以通过以下方式导入现有订阅：

使用 Stripe API。
使用 Billing 迁移工具包

离开您的支付服务商后，确认他们取消了您客户的所有自动账单。

迁移 PGP 密钥

如果您不熟悉 PGP，请参阅 GPG 并从导入公钥开始。熟悉 PGP 基础知识后，使用以下 PGP 密钥加密敏感数据（如信用卡信息）以进行符合 PCI 的迁移。

PGP 迁移密钥

这将创建包含以下信息的 FILENAME.gpg：

Key ID: 9C78B7620C1E99AD
Key type: RSA
Key size: 4096 bits
Fingerprint: AEBF 7C48 38C4 4D2F DC99 A3F9 9C78 B762 0C1E 99AD
User ID: Stripe Import Key (PCI) <support-migrations@stripe.com>

导入我们的密钥后，可以通过在命令行提示符下运行以下命令来加密要发送的文件：

gpg --encrypt --recipient 9C78B7620C1E99AD FILENAME

有关向 Stripe 提供加密数据的更多详细信息，请参阅上传补充数据。