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?
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).