PHP信用卡支付网关集成

发布于 2024-09-12 11:21:18 字数 162 浏览 3 评论 0原文

我需要开发一个需要与信用卡支付网关集成的应用程序,因此为了进行测试,我需要一个免费的开发人员帐户或任何其他可能的帐户,以便我可以检查支付处理是否正确。

因此,如果存在一些允许创建免费帐户进行测试的支付网关,请指定我。

如果没有,还有其他解决方案吗,该应用程序不支持 paypal

I need to develop an application which requires integration with credit card payment gateway and hence for testing i need a free developer account or any other possible account so that i can check whether the payment processing is correct or not.

So please specify me, if there exist some payment gateway that allows the creation of a free account for testing.

If not is there any other solution,the application doesn't support paypal

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

故事还在继续 2024-09-19 11:21:18

Authorize.Net 有一个可以集成的开发环境。

Authorize.Net has a development environment you can integrate with.

眼泪都笑了 2024-09-19 11:21:18

您可以向 Authorize.Net 申请免费测试帐户。您可以像进行实时集成一样测试他们的所有 API,而无需支付任何费用。

You can apply for a free test account with Authorize.Net. You can test all of their APIs as you would for a live integration with no cost to you.

垂暮老矣 2024-09-19 11:21:18

没有两个信用卡 API 是相同的,不要集成您不打算使用的 API。

此外,每个信用卡处理商都会有自己的怪癖,只是因为您找到了一个喜欢的信用卡处理商您的 API 调用并不意味着您打算使用的人会喜欢您的 API 调用。

请注意,即使规范中的术语也有很大差异,授权有时称为保留,预授权,捕获有时称为完成或收费,购买有时称为销售,授权...... Oo

简而言之:

如果您实现一个 API ,它没有任何价值来判断另一个 API 是否可以工作


通常,信用卡 API 分为 2 个基本类别:

  1. 表单 API - 3d secure 始终在支付处理器端实现,您不需要当信用卡数据在处理商的站点上输入时,无需采取任何措施来确保 PCI 合规性 - 在 90% 的情况下,您所需要做的就是向支付处理商远程提交表单并在处理交易时捕获回调
  2. 直接 API - 在 90% 的情况下,您必须实施 3d secure,并且您需要确保在您的网站上输入信用卡数据时至少符合 PCI DSS(不存储完整的 PAN 和 CVV, SSL 证书,...) - 这通常包括 2 个用于处理授权的 API(授权/购买和提交提交)和用于退款、获取授权和无效授权的 API

注意,您通常可以使用表单 API 来进行授权和用于捕获、退款和作废的直接 API。

请参阅针对商户的 PCI DSS 自我评估问卷

除此之外,深入探讨会过于宽泛,在我详细说明之前,您需要指定您要进行哪种类型的集成。

要查看 CC api 的示例,只需在 google 中搜索“信用卡处理 api”,我建议您查看其中的几个,以便对许多 API 中的相似之处和不同之处有一个总体感觉。

No two credit card APIs are the same, don't integrate an API you don't intend to use.

Also, every card processor will have his own quirks, just because you found one card processor that likes your API calls doesn't mean that the one you will intend to use will like your API calls.

Note that even the nomenclature in the specifications differs widely, authorizations are sometimes called reservations, preauthorizations, captures are sometime completions or charges, and purchases are sometimes sales, authorizations..... O.o

In short:

If you implement one API, it has no merit on judging if another API will work


Generally, credit card APIs fall into 2 basic categories:

  1. form APIs - 3d secure is always implemented on the payment processor side and you don't need to do anything to ensure PCI compliance as credit card data is entered on the processor's site - in 90% of cases all you need to do is remote submit a form to the payment processor and catch a callback when transaction is processed
  2. direct APIs - 3d secure must be implemented on your side in 90% of cases and you need to ensure a minimum of PCI DSS compliancy as credit card data is entered on your site (no storing of full PAN and CVV, SSL certificate, ...) - this one usually included 2 apis for processing authorizations (authorize/purchase and pares submit) and APIs for refund, capture of authorizations and void of authorizations

Note, you can usually use a form API to do authorizations and direct API for capture, refund and void.

See PCI DSS Self Assessment Questionnaires for Merchants

Other than that, going deeper would be going too broad, you will need to specify what kind of integration you are going for before I could elaborate.

To see examples of CC apis just google for "credit card processing api", I suggest you take a look at several of them to get a general feeling for things that are similar in many APIs and things that are different.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文