延迟链式支​​付与授权/捕获 + 批量支付 - 用例场景

Posted 2023-02-22

【中文标题】延迟链式支​​付与授权/捕获 + 批量支付 - 用例场景

【英文标题】：Delayed chained payments vs. Authorize/Capture + Mass Pay - use case scenario

【发布时间】：2014-09-21 09:04:10

【问题描述】：

我的用例：买家从卖家那里购买服务，我们的应用程序促进并保证了交易。它应该以买方将钱寄给我们的方式工作，我们检查买方是否收到了服务，在这种情况下，我们将钱寄给卖方。否则我们退款给买家。重要的是为买家提供 2 种支付解决方案：paypal 账户和无账户卡支付。整个用例是国际化的。 我正在沙盒环境中对此进行测试。

可能的解决方案：

自适应支付 - 延迟链式支​​付： 工作正常。缺点是卖家必须授予我们许可才能退款。这里的问题是权限 api 正在维护中，所以我正在等待所有更改 https://developer.paypal.com/docs/classic/permissions-service/integration-guide/PermissionsWhatsNew/ 。这有什么大不了的吗？

快速结帐授权/捕获+批量支付： 工作正常。这里的好处是，如果退款（授权后无效），我们不必支付费用。这里的缺点是我不确定授权是否持有资金，这样即使没有账户用卡支付的买家也无法接触到钱，我可以在 3 天内将它们捕获。另一个问题是，当我从 30 美元余额的 PayPal 帐户授权 40 美元时，我捕获了全部 40 美元。怎么会？

我以前没有使用 PayPal 的经验，我现在该应用程序应该可以在国际范围内使用。如果您对此用例有任何提示、文章或实践经验，请分享！

---

编辑： 延迟链式付款很棒。我通过使我的应用程序成为次要接收者和卖方主要接收者解决了这个问题。如果退款，卖家必须授予我的应用权限，但没有更好的方法。

但是，现在的问题是，当买家无账户付款（客人付款 - 使用卡）时，所有收款人必须是商业或高级账户持有人：

每位客人付款的收款人必须是经过验证的 PayPal 企业或高级帐户持有人。

来源：https://developer.paypal.com/docs/classic/api/adaptive-payments/Pay_API_Operation/

问题在于，即使主要接收者（卖家）不是 Business 或 Premiere 帐户，它在 sanbox 中也能正常工作。怎么了？

【参考方案1】：

1) 您是否将自己设置为主要接收者？如果是这样，我认为您不需要授予权限，除非您已经运行 ExecutePayment 将资金推送到辅助收款人帐户。如果您在此之前退款，则不需要权限（尽管我没有专门对此进行测试，所以我可能是错的。）

2) 关于费用，如果您退还通过 Adaptive 进行的付款，那么 PayPal 会将费用退还给您，因此您在这里并没有真正获得任何收益。

授权可能很棘手。我理论上，授权资金应该保证 3 天，但你仍然在 30 天（或 60 天）内捕获，即使它可能有也可能没有资金可用（它只会成功或失败）。

您可以在前 3 天后运行重新授权，以获得额外 3 天的保证资金，但我认为您最多只能这样做一次。

不过，这在很大程度上取决于发卡银行。尽管 PayPal 的文档可能会指定有关授权如何工作的某些内容，但如果发卡银行有与其信用卡相关的不同规则，可能会导致事情失败。

至于为什么当 PayPal 余额仅为 30 美元时，40 美元的授权会起作用，我认为这可能是因为二级资金来源。如果您在帐户中设置了银行帐户和/或信用卡，那么如果仅 PayPal 的资金无法支付，PayPal 会假设它可以从这些来源中提取资金。根据您的用例，这可能是理想的，也可能不是理想的。

【参考方案2】：

您在这个问题中混合了多个概念。有不同的 PayPal PAYMENT 产品（适用于链式付款与快速结帐），然后是授权与即时付款的问题。

同意 Andrew 的观点，即退款案例中的费用不是选择解决方案的正确依据。更重要的是发送方和接收方将在他们的帐户中看到什么（向您/从您付款，或从/向另一方付款？），整个系统的简单性/可靠性（您一方的错误是否会导致失败或多次付款?)、责任，甚至监管问题（例如，您是否充当托管服务？）。

如果 PayPal 向您提供来自 PayPal 买家的授权，则意味着 PayPal 保证（除了某些非常有限的例外）它将在指定的时间和金额限制（可能会因具体情况而异）内兑现这些资金. PayPal 可能会根据发件人的余额、信用卡、银行账户或多种因素的组合做出该保证。作为收款人的您无需关心——那是在 PayPal 和买家之间。 （适用于该身份验证的是 PayPal 的限制/条件，而不是发件人的基础信用卡/银行/等的条件；PayPal 可以保护您免受这种复杂性的影响。）

相反，如果身份验证来自卡网络而不是 PayPal 帐户（即用户提供卡信息而不是使用 PP 帐户，无论 PayPal 是否是您的支付处理器），那么该网络指定并控制条件的授权。

PS：如果您正在等待自适应付款更改，您可能需要等待很长时间。 89 版是很久以前的事了，PayPal 的优先事项是 RESTful API，而不是自适应。

【讨论】：

您引用的消息似乎明确告诉您要求；如果您想要不同的行为，您可能需要考虑使用不同的支付产品。没有在沙盒中验证需求这一事实可能是一个错误。另外我应该澄清一下：虽然我确实在 @ PayPal 工作（因此可以解释第 89 版的评论），但我现在不在那里工作，也无法为你查看代码。

另外，虽然这对您的客户（卖家）来说可能不方便，但据我所知，个人账户和高级贝宝账户之间不再有任何区别（他们曾经有不同的费用结构，但几年前就结束了）。因此，您可以要求您的卖家将他们的帐户从个人帐户升级为高级帐户。坦率地说，这是 PayPal 在处理 b/c 方面做得很糟糕的事情，大多数人，即使是在公司内部，也从来没有理解账户类型之间的预期差异......导致了很多奇怪的行为，就像你在这里看到的那样。