Authorize.net 无提示发布和测试模式
将 AuthNet 的自动定期计费系统与其 Silent Post 功能集成，在我们团队的 Web 应用程序中创建付费功能系统。无声帖子功能的文档很少，但我在 SO 上遇到了一些有用的线程以及我们的成员撰写的一些博客文章（尤其是 约翰·康德的 "所有关于无声帖子”）来帮助引导道路。我有一些更专业的问题，但我希望你们中的一些经验丰富的人能够提供帮助。
Authorize.net 文档包含此通知：
测试环境账户不处理ARB订阅交易。如果您正在使用 如果您是测试环境帐户，您将不会收到任何形式的这些电子邮件通知。你 在使用 Silent Post 时也将无法接收 ARB 订阅交易 测试环境帐号。
我想知道是否有人知道这是否意味着在控制面板中将帐户设置为“测试模式”，或者这是否指那些在独立于部署的 AuthNet 平台上工作的人员可用的仅限开发人员的帐户？我们用于测试的帐户是在测试模式下设置的实际商家帐户，并且我们正在收到通过 AuthNet CP 完成的虚拟终端付款的静默帖子，但即使是成功的 ARB 也不会显示静默帖子。
另外 - 可以使用什么样的参数来确保静默帖子源自 AuthNet？我设置了一个端点，并从静默帖子以及 $_SERVER 超全局中打印出请求对象 - 除了 CP 中设置的 MD5 哈希值之外，它们似乎没有发送任何标识。这很好，但我想知道限制到特定的远程地址是否有任何优势 - 我认为这不太可能，因为这些帖子可能来自一个数据中心，该数据中心分配了大量的 IP 来执行发送静默帖子的任务。
此外，ARB 规范仅在非常具体的条件下将 AuthNet 内的订阅状态设置为“暂停”（仅当付款失败是第一次重新计费，如果不是，则在随后几天的两次尝试后）。这是暂停订阅的正常做法吗？如果我们想要一次拒绝触发暂停，那么撤销该功能的逻辑是否也应该发出 UpdateSubscription API 调用并手动设置为暂停以放弃默认规范？
Been integrating AuthNet's Automated Recurring Billing system alongside its Silent Post feature to create a paid features system inside our team's web app. The silent post feature has slim documentation, but I have come across several helpful threads on SO as well as a few blog posts authored by our members (especially John Conde's "All about Silent Post" ) to help guide the way. I have a few more specialized questions however I was hoping some of you more seasoned folks could help out with.
The Authorize.net documentation includes this notification:
Test environment accounts do not process ARB subscription transactions. If you are using
a test environment account, you will not receive these email notifications in any form. You
will also not be able to receive an ARB subscription transaction Silent Post while using a
test environment account.
I was wondering if anyone knew if this means accounts set to TEST MODE in their control panels, or does this refer to the developer-only accounts available to those working on AuthNet platforms independent of deployments? The account we are using for testing is an actual merchant account set in test mode and we're receiving silent posts for virtual terminal payments done through the AuthNet CP, but even successful ARB's are not showing silent posts.
Also - what kind of parameters can be used to ensure that a silent post originated with AuthNet? I set up an endpoint and printed out the request objects from a silent post as well as the $_SERVER superglobal - it does not seem that they send any identification other than the MD5 hash set in the CP. This is fine, but I was wondering if there would be any advantage to limiting to specific remote addresses - I assume this is unlikely as the posts probably come from a datacenter with tons of IPs allocated for the task of sending silent posts.
Also, the ARB spec only sets a subscription status to SUSPENDED within AuthNet under very specific criteria (only if the failed payment is the first rebill and if not then after two attempts on subsequent days.) Is this a normal practice for suspending subscriptions? If we would like to make one decline trigger suspension, should the logic for revoking the feature also issue an UpdateSubscription API call and set to suspension manually in order to forgo the default spec?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这指的是两者。任何测试 ARB 交易都不会被处理，也不会生成静默帖子。这可能就是为什么他们的开发者论坛上充斥着有关测试 ARB 的问题。基本上，除了设置实时订阅之外，在测试时您可以做的最好的事情是：
无声帖子中返回的 MD5 哈希值是一个字符串的哈希值，其中包含一个 MD5 哈希值（在安全设置中设置），大概只有授权并且您知道。因此，您可以使用返回的信息加上秘密哈希字符串在端生成一个哈希，并进行比较以验证响应。有关哈希值的详细信息可以在此处找到。
正常练习吗？老实说我不知道。我不确定其他公司是如何处理的。在他们的 社区论坛 的某处有一个帖子，其中 Authnet 员工解释了它的工作原理，但我找不到链接到这里。当我读到它时，它对我来说很有意义。
如果订阅失败，Authorize.Net 会自动暂停订阅，因此您无需执行任何操作。但您确实需要更新系统中的用户帐户并将其暂停（假设订阅是针对某种用户帐户）。
This refers to both. Any test ARB transactions will never be processed and not generate Silent Posts. It's probably why their developer forums are riddled with questions about testing ARB. Basically, the best you can do when testing it, besides setting up a live subscription, is to:
The MD5 hash returned in the silent post is a hash of a string that includes an MD5 hash value (set in security settings) that presumably only Authorize and you know. Thus, you generate a hash on your end using the returned info plus the secret hash string and compare to validate the response. Specifics about the hash can be found here.
Normal practice? Honestly I don't know. I'm not sure how other companies handle it. There's a post somewhere in their community forums where an Authnet employee explains how it works but I was unable to find it to link to it here. It made sense to me when I read it.
If a subscription fails it is automatically suspended by Authorize.Net so you don't have to do anything on your end. But you do need to update your user's account in your system and suspend it (assuming the subscription is for a user account of some kind).