0

我应如何将自定义购物车应用程序与 PayPal 集成以接受间接信用卡付款，而无需强制买家在 PayPal 注册？

有一个自定义购物车 Web 应用程序，任务已设置为使用 PayPal 替换当前的信用卡/银行卡付款。目标是让客户通过 PayPal 用他们的卡付款。但是，有一些限制：

  1. 客户不应在购物车页面而是在 PayPal 页面中输入他们的信用卡详细信息（号码、有效期、安全代码），
  2. 如果订购的物品可用并且可以交付，则每次付款都必须包括授权（冻结总金额）和后续捕获，
  3. 如果客户希望通过卡付款，则无需创建/登录 PayPal 帐户。

问题是我真的对 PayPal 可能的选项数量感到困惑。REST API 和 Classic API 之间的选择没有那么大的问题，但是从整个列表中选择合适的产品（如Classic API 产品或REST API 产品）对于 PayPal 新手来说并不是那么明显。其他一些类似的问题指向DoDirectPayment（但我不知道它是否是最佳选择）或建议网站支付标准（我不确定它们是否仍然可用）。我也在考虑 Express Checkout，但演示似乎强制创建 PayPal 帐户。

4

2 回答 2

0

ExpressCheckout 旨在与直接信用卡接受方法（例如 PayPal 的 DoDirectPayment 或非 PayPal 信用卡接受方法）配合使用，尽管它可以配置为也进行客人付款。这就是为什么普通配置的演示只处理 PayPal 帐户创建；这是正常的用法。

您需要问自己的一个关键问题是您是否想访问信用卡信息并自己成为“记录商家”。

是：这样做可以为您提供最大的灵活性，但即使您使用一些试图使您与实际原始卡号保持距离的解决方案（例如收集它们），您也需要通过一些商家审查并承担一些安全义务 (PCI)通过 PayPal 或 Braintree 代码并立即加密和标记它们）。简而言之：如果您想完全访问卡，那么您有法律义务：处理该技术可以减少但不能消除的帐户访问。

否：如果您愿意始终通过 PayPal，通过 PayPal 账户的法律结构（无论用户实际上拥有 PayPal 账户还是只是在他们提供的 PayPal 上进行“客人”付款PayPal 一次性使用他们的信用卡）然后您可以减少您的审查和安全限制（根本没有 PCI 要求）。

如果您想（或需要）访问客户的卡 [上面是）。HSS 满足上述所有 3 项要求；DDP 不符合要求 #1。

如果您可以访问客户和付款，但不能访问卡帐户本身 [以上没有]，那么您可以使用网站付款标准或带有访客结帐选项的 EC；两者都满足您的所有三个要求。

上述所有解决方案不仅仍然受支持，而且拥有数万或数十万家集成商户，是处理 PayPal 支付的最大/主流方式。

如果您更喜欢较新的产品并且属于上述第一类（真实卡访问，而不是客人付款），那么您还可以使用 Braintree 或 RESTful API。这些较新的产品还没有旧产品那样的灵活性和覆盖范围，但是嘿，只要它们满足您的需要，降低复杂性可能是一件好事。这些产品通常是围绕您的网页插件设计的，而不是在 PayPal 网站上输入卡信息，因此它们不符合您的第一个要求。

您也可以使用 PayFlow（多种变体）或自适应支付或或或.... 但总的来说，我建议选择最完善的或新的和不断发展的选项，因为它们得到更好的支持和更面向未来。

于 2015-07-13T13:21:36.513 回答
0

现在 PayPal 已经收购了 Braintree，首选的集成方法是v.zero。它被设计成非常容易接受 PayPal、信用卡和其他选项。（Venmo、比特币等）

于 2015-07-15T23:38:22.140 回答