Omnipay 和 Payum 之间的区别

Difference between Omnipay and Payum

我正在为我的网络应用程序寻找支付解决方案。我看到有像 stripe(用于信用卡)或 PayPal 插件这样的 API 可以处理某些支付方式。

然后我看到有一些库可以处理各种支付方式,例如 Payum (https://github.com/Payum/Payum) or Omnipay (https://github.com/thephpleague/omnipay)。

如果我理解正确的话,它们都是同一类型的图书馆:它们都以标准化的方式处理各种方法的付款。但是我没有找到两者之间的任何比较,而是 Payum 如何包含 OmniPay 的解决方案。所以我很困惑。因此我的问题是:

Omnipay 是否涵盖与 Payum 相同的用途。如果有,哪一个有什么优势。如果不是,他们具体实施了支付流程的哪些部分。

Payum vs Omnipay

简短的回答是 Payum 提供与 Omnipay 相同的功能以及一些额外的功能。

当您将支付模式与转换操作结合使用时,Payum 的效果最佳。该模型不能只是一个 Payum’s one, I encourage you to use your own or one from a ecommerce platform. The idea is simple: you send a request to Payum to capture your model. In the action you convert the payment model to a gateway specific format,很可能是一个数组。这种方法的美妙之处在于您的代码永远不会更改,并且看起来像这样:

$gateway->execute(new Capture($payment));

所有网关的差异都隐藏在一个网关内。当然,Payum 支持特定于网关的格式,或者 Payum 的支付模型。在 Omnipay 的情况下,您不能简单地将条带网关替换为贝宝网关,因为它们的行为不同,更重要的是它们需要不同的数据。 Stripe 要求提供信用卡,而 Paypal 不关心它,而是希望设置 return 和取消 urls。你必须在你的代码中反映这些差异,这是抽象吗?顺便说一句,Payum 为您生成取消和 return url,它们是安全的(我们稍后再讨论)。

有时您必须获得有关付款交易或付款人的更多详细信息,或有关错误的更多信息。 Payum 允许您访问参与您的代码和支付网关之间通信的所有数据。数据格式是特定于付款的,因此如果您熟悉 Paypal protocol (for example),那么您将很容易理解那里发生了什么。另一个很好的例子是 Klarna Checkout。它returns shipping\billing 地址、性别和出生日期。使用 Payum,您可以轻松地从付款中取出这些并用于您的需要。

Payum 为您提供更好的状态处理。 Omnipay 只提供成功和失败两种状态,但这还不够。例如 Paypal 有时 return 的待定状态是因为 multi currency issue. In this case omnipay says the payment has failed, but in fact it is not. Or user can cancel the payment at Paypal side, Omnipay will tell you it failed but it is not really true. If you need a status which is not provided by Payum by default, you can easily add it. Do you already have payment statuses, maybe your ecommerce platform provide 它们并且您想重复使用,没问题 Payum 可以调整以使用它们。

有时用户想要欺骗您或支付更少的费用。作为开发人员,您必须考虑并保护好您的数据。你向用户展示什么?会不会用错了?在您验证它之前,您不能依赖 url 中给出的金额。例如,Paypal 会向您之前发送给他们的通知 url 发送推送通知。 Payum 为您生成这样一个 url ,当通知返回时它会验证它。您将获得开箱即用的独特且安全的 url。与 url 内部关联的付款,一旦您 remove\invalidate,url 用户将无法访问其背后的付款。 Omnipay 不提供任何东西来帮助您解决安全问题。这些安全的 urls 有一个很好的副作用。安全的 urls invalidated\deleted 一旦他们不需要。这很好,例如用户在浏览器中单击“后退”按钮。他将无法进行第二次付款,因为购买 url 不再存在,相反他会看到 404 错误。

把信用卡放在身边不是一个好习惯,不是吗?没有理由不小心或只是几秒钟存储它。 Payum 有一个 sensitive value 对象,可确保不会意外保存任何内容。您仍然可以存储它,但在这样做时您只能靠自己了。

Omnipay 仅支持重定向到网关端或需要信用卡的网关。但是还有许多其他网关,它们的行为不同。例如 Klarna Checkout require a snippet (iframe) to be rendered, Stripe.Js requires their javascript to be executed on a purchase page. Stripe Checkout renders its own popup. Payum supports them all, and as we talked at the beginning you can switch from one gateway to another without changes in your code. Payum does not natively supports a gateway you need? I do not think reimplementing every gateway in house is a good idea. That’s why a bridge for Omnipay gateways exists。它允许您以 Payum 方式使用 Omnipay 网关。

Payum 尝试 standardise the payment flow。准备、capture\authorise 和完成三个步骤。第一个称为“准备”,在此步骤中,您必须准备付款、计算总价、税金、获取用户或运输信息等。完成后,您可以将用户重定向到 capture\authorise 步骤,从这里用户可以被重定向到网关端或要求提供信用卡或其他内容。这取决于您选择的网关。在“完成”步骤,您必须获得付款状态并根据它采取行动。 Omnipay 只部分解决了这个任务。

使用网关工厂,您可以轻松地 overwrite\replace 网关的任何功能部分,或添加自定义操作、扩展或 API。

Payum 拥有大多数现代框架的官方扩展,例如 Symfony. Laravel, Silex, Yii, Zend

最后让我们比较一下 Payum 和 Omnipay 的基石接口。

免责声明:我是 Payum 的作者