Handling Authorize.Net ARB Subscription Failures
One common complaint about the Authorize.Net Automated Recurring Billing (ARB) system is that there is no way to handle subscriptions that are declined when processing a future scheduled payment. As it turns out there is a way to handle this failures programmatically and automate your response to them.
Authorize.Net has a little known, and poorly documented feature called Silent Post URL. This is a URL that you specify where the results of all transactions are posted. This is in addition to the response given via their API.
The results of all transactions, including those processed using the Advanced Integration Method, are posted to this URL. This means you will be responsible for determining which are real-time transactions and which are using the ARB API. How you can do this is quite simple. When an ARB transaction’s results are posted two extra fields are included:
x_subscription_id - This is the ARB subscription ID of the transaction processed. You should probably already have this stored in a database somewhere.
x_subscription_paynum - This is the number of the occurrence of the subscription that failed. If this was the fifth recurring transaction for that subscription the value of this field would be ‘5′.
You can look for the presence of either of these two fields to indicate the transaction is an ARB transaction and act accordingly.
Here is some sample PHP code for handling a response posted to the Silent Post URL:
// Flag if this is an ARB transaction. Set to false by default.
$arb = false;
// Store the posted values in an associative array
$fields = array();
foreach ($_REQUEST as $name => $value)
{
// Create our associative array
$fields[$name] = $value;
// If we see a special field flag this as an ARB transaction
if ($name == ‘x_subscription_id’)
{
$arb = true;
}
}
// If it is an ARB transaction, do something with it
if ($arb == true && $fields[’x_response_code’] != 1)
{
// Suspend the user’s account
…
// Email the user and ask them to update their credit card information
…
// Email you so you are aware of the failure
…
}
To set the Silent Post URL simply login into your Authorize.Net control panel and click on your Settings links. It will be one of the options on that page. Simply add the URL you want them to post the responses to and submit it. It will take effect immediately.
So, if you have read our article Integrate the Authorize.Net Recurring Billing API with PHP and wanted to find a way to handle recurring billing failures in an automated fashion, then this solution should be music to your ears.
July 9th, 2008 at 5:03 pm
Obviously, you haven’t done your research. Everyone knows about the Silent Post feature. The problem developers have with it is that it only works for successful transactions. It doesn’t work for declined or failed transactions.
Before you lambast as me another idiot beginner who “just hasn’t implemented it right” understand that I am a senior architecture with 5 years of experience integrating systems and working with SOAP/WSDL, REST and convention Form POST methods.
I’ve setup pages to use the Silent Post feature on half a dozen different applications, including ones using ARB. We’ve even added packet sniffers to our hosting cluster to see if some posts are being filtered out before they get to our page. No dice. All successful transactions come through; none of the declined ones do.
This is the case no matter what hosting provider we use. I have sites with at least three different hosts : Mosso, The Planet and CrystalTech. The host doesn’t matter. Declined transactions are NOT posted to the Silent Post URL.
We’ve documented this issue heavily and tried talking with Authorize.Net management who will not discuss the issue. The front line customer service at Authorize.Net, as everyone who has used them knows, is a complete joke. They have no working understanding of the technology or even what transpires between requests and responses at the gateway. They only reply with copy/pasted information from the web site.
So, before you write a blog post telling the world that failed transactions work, do your homework and actually set it up and TRY IT first. You’ll see that it doesn’t.
If there’s anything I hate, it’s bloggers who copy/paste info from web sites and declare “a solution in plain site”. Those of us who are down in the trenches, working with Authorize.net, fully understand what works and doesn’t. We’ve scoured the net looking for answers to the failed transactions issue. There isn’t one. Authorize.Net DOES NOT SUPPORT them. Period.
July 9th, 2008 at 5:26 pm
Since you took a very negative tone in your comment I will have fun embarrassing you.
Firstly, I have twice as much experience as you in this arena so I don’t recommend trying to sound special by saying you’ve been doing this for 5 years. You just sound like a newbie.
Secondly, if you had bothered to read this blog post you would have noticed we’re talking about using the silent post feature for Authnet’s ARB service. Not their AIM service. It’s in the title if you want to read it again. And I have tested it. Silent post DOES work with declined ARB transactions. Have you tested it? Obviously not.
Thirdly, there is a solution for handling declined transactions: they’re still on your website stupid! You can do whatever you want! Did you ever consider that? If the card is declined Authnet tells you right away and you can handle it anyway you want including logging it into a database and/or emailing someone. If that never occurred to you then maybe you should consider a new field to work in as after five years that should have been obvious to you.
So, newbie, instead of ranting about how awful Authnet is and calling others copy and pasters, maybe you should learn how to read content and comprehend their meaning as well as get more experience integrating and using Authnet’s services.
Oh, and thank you for the laugh.
July 16th, 2008 at 9:18 am
I should really visit this blog more often. You’re amazing. I don’t know how I never came across this either… it’s definitely not mentioned in the ARB docs (or not prominently enough). I might not have switched over to CIM for recurring billing had I known there was the equivalent of PayPal IPN for ARB! Oh well, this is more flexible anyway :)
September 2nd, 2008 at 4:06 pm
Props on your response to Jon H.–very funny, what a boner… Thanks also for your info on the Silent Post–I think Jon H. must have written the Authorize.net documentation for Silent Post as it relates to ARB. Your simple post here is more helpful that ALL the documentation they have. Nice work!
September 3rd, 2008 at 9:23 pm
I would like to add the following facts and opinions…
1) silent post was unknown to me
2) your tutorials are more helpful than anything AuthNet has out there
3) John H may be a newbie; however, he is very experienced at being a douche bag.
September 3rd, 2008 at 10:40 pm
Hi John,
Thanks for the information about the Silent Post URL for ARB subscription.
There is one question related to use of “Silent Post URL” for which I am searching for an answer. I feel or rather believe that you might be having the answer to that.
Let me put the scenario, for which I am finding solution, in front of you:
I am presently working on one of my client’s site which is using Authorize.NET payment gateway for accepting the payments from customer. In the site we are presently using API and CURL to make transaction request and receive the response back from payment gateway.
In the site, we are also providing the facility to the customer to make the payments in installments by creating a recurring billing subscription for them.
As an add-on feature, my client wants to trap the transaction details related to recurring billing subscription so that we can store those responses on our site and display it to the customer when the customer access the transaction detail page on our site.
In the PDF document provided by payment gatewaysite , they are mentioning that the only value to receive the transaction details for recurring billing subscription is through the use of Silent Post URL. In this feature, we need to specify the URL of our site where the response related to transaction status will be sent after the transaction in name=value format. The document also mentions that Silent Post URL is enabled, responses from both recurring billing subscription and all other regular transactions will be posted to this specified URL.
What my concern is that after enabling this feature, will the response to transaction request using API and CURL be posted to this specified URL or will it be posted back to the same page from where the transaction request was made using API and CURL.
Please help me in finding the answer to this question.
Thanks in advance.
Best Regards,
Chirayu Tailor
September 4th, 2008 at 7:52 am
Chirayu,
The answer to your question is the response will be sent back to the page calling their API. The Silent Post functionality will also receive a response but it will be formatted differently then their API response. When processing a live transaction it is always best to use the direct response sent using their API to handle responses as that will allow you maximum flexibility in handling the response. The Silent Post functionality should be reserved for other tasks that aren’t needed to be handled immediately or occur after the transaction is over (e.g. future recurring billing transactions). So in your case, the Silent Post functionality would be perfect for recording a customer’s history of their their recurring billing payments.
September 5th, 2008 at 4:46 am
Hi Jhon,
Just a silly doubt ,
Is Authnet provide Silent Post functionality in in test account i.e ‘https://test.authorize.net/ ‘ , Can I set it in test account ? If not, then I need a full fledged merchant account , where I can set the notification mail address and Silent Post URL , right ? If yes, then for testing would I require to exchange real money thru Authnet ??
September 5th, 2008 at 1:26 pm
Sagar,
I haven’t tried setting up Silent Post in a test account so I am unsure if it works or not. I say give it a try and see what happens. If works that’s great. If not, maybe you can try it out on your first ARB client.
September 5th, 2008 at 10:48 pm
Hi John,
Thanks for the valuable reply,
The main thing is that I had searched each nook and corner of my Authorize.net test account , but nowhere I was able to find the ‘Silent URL’ kind of thing and they warned us to not to change a single thing from there test account (as its shared by many other test users). I googled this , but no results found !
I`m just afraid that Is it there somewhere in test account OR Authnet at all not provide this functionality ! If they do not , then they should , because its a vital functionality for developer like us who automated the billing process at server side ! (and I found no single reason to avoid it !)
Anyways , Thanks for the help ! I`m gonna tell my Boss that we need one real merchant account now ..
September 28th, 2008 at 11:14 am
Useful information. I had read about Silent Post before, and I’ve actually had it setup for several months to email me notices (I had just started using A.NET with a new site and just loved the feeling of getting a email saying I had a new subscriber…haha). I do not believe it is documented well, but there is a setting in the gateway for it that states it will post transaction details - I found it while browsing the gateway.
I also understand where Jon H. is coming from - a little I guess. The Silent Post is not sent for everything. Here is what we have directly from the ARB implementation guide:
“The Silent Post feature only returns responses for scheduled ARB transactions that are approved or declined. The payment gateway will not return a response to the specified Silent Post URL if the scheduled transaction results in a general error due to expired or invalid payment information. For more information see the “General Errors for Individual Payments in a Subscription” section of this guide.”
Thus, we get posts for approved and declined payments. But it states we will not get them for general errors due to expired payments or invalid payment information.
Anyways - it seems that the web is filled with people saying Silent Post only works for successful transactions, but I know from experience that I get notifications for declines as well using ARB. As for general errors, I do not recall specifically if I receive posts for these (the only that applies to me is credit card expiration). The ARB guide states general errors are:
Credit card # or expiration date expired
gateway was in test mode at time of scheduled payment
eCheck.net disabled
NOC (notification of change) for eCheck received
The only general error above that would apply to most people (unless accepting eChecks) would be the credit card expiration. Whether or not Silent Post works for that I am not sure. If not, I’m not sure how to get around that issue automatically. But other declines do send notification - I’m sure.