前端的StripeConfirmCardPayment与后端的paymentintent.Confirm

哈喽！今天心血来潮给大家带来了《前端的StripeConfirmCardPayment与后端的paymentintent.Confirm》，想必大家应该对Golang都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习Golang，千万别错过这篇文章~希望能帮助到你！

什么时候你会在前端选择confirmCardPayment，什么时候你会在后端选择 paymentintent.confirm？

目前，我们的应用程序允许您以访客身份结账，如果您不是访客，则可以保存信用卡，或者使用已保存的卡。

所有这些流程都可以在前端没有 confirmcard payment 且在后端没有 paymentintent.confirm 的情况下工作

我猜有一天卡支付需要额外的身份验证，那就是我们需要在前端确认或在后端确认的时候？ （此外，何时/为什么卡需要额外的身份验证？这个领域的新手并希望学习）

我们的代码几乎遵循以下内容：https://github.com/stripe-samples/ saving-card-after- payment/blob/master/without-webhooks/server/go/server.go

PS：上述链接的 TLDR 是：

前端：

• 使用给定卡或已保存的卡创建付款方式。
• 将 POST /pay API 发送到后端

后端：

• 接收 API（验证用户是否经过身份验证 - 在我们的例子中）

• 使用前端的 paymentmethodID 和从后端获取的 customerID 创建要发送到 stripe 的付款意图（我们之前创建的 Stripe 的客户 ID） Stripe 向我们返回带有状态的付款方式。

双方都没有确认。

如果其他客户尝试使用相同的付款方式，则会失败。 如果同一客户使用相同的付款方式（已保存的卡行为），则有效。

正确答案

我猜有一天卡支付需要额外的身份验证，那就是我们需要在前端确认或在后端确认的时候？

您需要在前端执行此操作，因为客户身份验证是的。在前端确认尝试付款，Stripe JS 库还将显示所需的任何其他 UI，例如客户银行的 3D 安全身份验证页面。

这对于接受其他类型的付款方式也很重要（您应该这样做，因为在结帐流程中使用更多本地付款方式可以提高客户转化率）。例如，使用 iDEAL 付款需要重定向到客户银行，该银行同样在客户端处理。 https://stripe.com/docs/payments/ideal#payment-flow

（此外，何时/为什么卡需要额外的身份验证？这个领域的新手并希望学习）

目前欧洲和英国的任何交易都需要 3D 安全身份验证，而且这种做法在全球范围内只会变得越来越普遍

https://stripe.com/docs/strong-customer-authentication

https://stripe.com/docs/payments/3d-secure

https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date

我们的代码几乎遵循这个

您链接的 Github 链接/流程是使用 Stripe 的另一种方式，您可以在后端尝试付款，然后如果需要身份验证，则需要进行往返，但通常首选使用客户端确认，因为它更具可扩展性，可以接受其他付款方式。请参阅注释
https://stripe.com/docs/payments/accept-a-payment-synchronously

理论要掌握，实操不能落！以上关于《前端的StripeConfirmCardPayment与后端的paymentintent.Confirm》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！