使用ActiveMerchant和特定API之间的主要区别是什么？

Question

我是rails的新手，并开始了解如何集成付款处理。我正试图找到一个关于在哪里集中学习支付处理器集成的方向。

根据我的理解，ActiveMerchant是Shopify的一个提取，允许您轻松集成许多主要的支付网关，如Stripe和Braintree。我也理解这些平台也有自己的API用于特定服务。

如果将来有可能想要切换支付处理器，或者打算在不同站点使用不同的处理器，那么使用activemerchant似乎有明显的好处。

我的问题是将ActiveMerchant用作特定API的缺点是什么。如果我使用ActiveMerchant，我是否会对安全性采取更多的响应？它是否更复杂？

我的理由是，当我可以学习ActiveMerchant并在所有提供商中使用它时，我不想把我的时间和精力集中在学习特定的API上。

谢谢：）

Answer 1

我只使用过一次ActiveMerchant（用于电子商务系统），并且因为它与我们需要的相应支付网关集成而使用它

-

使用案例

你对“原生”API的问题在于，他们习惯在你最不期望的时候改变，让所有自定义（野蛮）工作最初实现它们时突然爆炸很难调试

我发现ActiveMerchant是Rails开发和开发之间的一个很好的“缓冲区”。支付提供商。如果Shopify获得报酬以处理其用户的付款，那么他们将提供最新的宝石以及他们的所有经验是一件好事

虽然您必须自己（仍然）管理大部分集成，但ActiveMerchent肯定是一个非常可靠abstraction layer来接受付款

-

<强>缺点

根据我的经验，主要的缺点是ActiveMerchant可能不支持特定API的一些更“利基”功能（例如，货币转换或类似）。尽管Shopify在所谓的[pull]请求中都非常自由地包含了功能，但你通常还是必须遵守他们的规范

要考虑的另一件事是您可能必须“弯曲”API以适合您的应用程序。在我们公司，我们有很多不同的方式来创造我们所需的财富，因此，我们不希望依赖与我们的提供商“接受付款”。

我们希望创建集成体验，这总是意味着让人们有机会购买高级帐户或应用内升级等内容。当您进入"micro payments"的世界时（我们绝对不会;我们只是有不同的方式来吸引买家），你开始必须通过使用非常自定义的实现来使API工作

-

<强>覆盖范围

从开发人员的角度来看，ActiveMerchant提供的主要好处是，您可以“覆盖”许多不同的支付提供商。

回到我关于API更改的评论，这意味着如果您正确地将您的应用与ActiveMerchant接口集成，那么<​​em>应能够与众多不同的支付提供商合作

supported providers is monumental的列表 - 意味着如果您想将支付服务提供商从Paypal更改为Stripe或其他内容，您可以通过不编辑大量核​​心代码来实现这一目标

-

<强>资源

最后，因为ActiveMerchant是一个基本标准，所以您将获得比使用各种AP​​I直接实现更多的支持。这反映在likes of Railscasts：

中