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, 2023 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, 2023 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, 2023 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, 2023 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, 2023 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) Jim H may be a newbie; however, he is very experienced at being a douche bag.
September 3rd, 2023 at 10:40 pm
Hi Jim,
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, 2023 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, 2023 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, 2023 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, 2023 at 10:48 pm
Hi Jim,
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, 2023 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.
October 11th, 2023 at 1:24 am
Hi Jim,
I have implemented this “Silent Post URL” in my website.
But i have 1 problem with that is on first payment of ARB, it is giving response on silent post URL after 24 hours.
So if there is a invalid creditcard number or any invalid information, it will accept that time and it will give approved status.
And after 24 hours, on silent post url, it will give true response like credicard is invalid or watever the reason for transaction declination .
So, i want help from you if it is possible to get immediate response on first transaction.
Regards,
Avee
October 11th, 2023 at 7:55 am
Avee,
That’s because you shouldn’t be using it that way. You need to read Integrate the Authorize.Net Recurring Billing API with PHP to see how to verify the credit card before setting up the subscription.
October 14th, 2023 at 4:22 pm
Russel (or Jim)…
Based on Russel’s post, if Silent Post does not let you know a payment has failed due to an expired credit card, how exactly should one go about determining if credit cards are expired and, in turn, deactivate a subscription or cancel an account (or at least send notification that they must update their billing info with a valid credit card)?
Any ideas?
October 21st, 2023 at 4:26 pm
great post! very valuable！
We are quite confusing about the mechanism of silent post, is silent post read data from authorize.net or authorize.net send data to silent post? we are not sure how to organize the code silent post. we tried to contact authorize.net, but they said they are just payment gateway, and do not provide the technical support for that~~~
by the way, does anybody can post a sample script about the silent post in PHP? this problem have been bothering us for whole day. or send us a copy to dluffup@gmail.com
very appreciated!
thanks guy!
October 23rd, 2023 at 3:00 am
Hi Jim, thanks! Very useful!
The only question I have is how can I validate a POST-request with a transaction response in my Silent POST Url script?
Does AuthNet provide any security hashes?
Or will it be enough to check the $_SERVER[’REMOTE_ADDR’] only to be sure that the request was sent by AuthNet? I think there are a lot of AuthNet servers that can send these requests.
You know, anybody can send fake POST-requests to my Silent POST Url to make be believe the subscription amount was successfully payed.
One more thing, AuthNet really does not even check SSL sertificate, if I set Silent POST Url to https://domain/silentPostUrl/
October 23rd, 2023 at 3:19 am
Sorry, I missed the ‘The MD5 Hash Security Feature’ in AIM_guide. I’m sure it will help me with my paranoia :)
October 23rd, 2023 at 10:35 am
Dohtar:
Just wanted to point something out. I have been working on this for a few weeks now so thought I would help. For ARB subscriptions, the MD5 hash is actually generated differently then for just regular AIM transactions. I am not sure why. I just tested it and this is what I came up with.
[YourSecurityCode][Transaction_ID][Amount] - ARB
[YourSecurityCode][UserAccount][Transaction_ID][Amount] - AIM
I havn’t fully tested it yet but I believe this is how it works.
October 23rd, 2023 at 4:01 pm
Jim, I’m not having any luck with the Silent Post feature. I’m emailing myself the contents of every Silent Post my url receives, and I’m not getting any data. There is nothing in FORM or URL scope. I’ve tried, several times, unsuccessfully, to get help from Authorize.Net. Can you provide any insight as to what I could be missing?
October 24th, 2023 at 10:18 am
@ Tek
It’s submitted in POST data, not in GET data.
(1) In PHP, try the $_POST[] super global.
data will be in this key/pair array, such as $_POST[’x_response_code’]
(2) If you’re using ASP.Net, try this:
byte[] b = new byte[this.Request.ContentLength];
this.Request.InputStream.Read(b, 0, Request.ContentLength);
string sAllPostData = System.Text.UTF8Encoding.UTF8.GetString(b);
data will be in sAllPostData as a huge block of text similar to how QueryString is formatted
Cheers,
-Pete
October 27th, 2023 at 12:55 pm
hi, Pete:
we are running out of luck on silent post features.
can you give us more hint about how to write a silent post file?
appreciated!
David
October 28th, 2023 at 8:49 am
Daniel:
Thank you, now the difference is quite clear for me.
But there’s another question.
As I listen to the not only AIM and ARB transactions but the CIM transactions too at my SilentPostUrl script, so I figured out that CIM-MD5Hash follows the same rules as ARB-MD5Hash:
[YourSecurityCode][Transaction_ID][Amount]
I didn’t find a word about it in CIM AuthNet guides. So this may help somebody.
Thanks again.
November 5th, 2023 at 3:29 pm
Great Article! Spot on! This has saved us a ton of manual ARB work.
One thing I just found out, that I thought I’d pass along, because it doesn’t make sense but Authorize.net apparently only suspends the ARB if the “first” attempt at charging a card fails. It seems odd to me that the account wouldn’t get suspended if ANY charge fails but the ARB_guide stated:
“A subscription will be suspended if the first payment in the subscription is declined, rejected or receives an error response.”
I just wanted to throw this out there, because I was trying to figure out why a users ARB was not canceled in anet when their second charge failed.
Cheers
M=
November 10th, 2023 at 8:36 am
Great post!
One question $fields[’x_response_code’] == 1 is the response for “OK”, diferent from 1 is charge denied or are the more detailed answers?
Thanks!
November 10th, 2023 at 10:17 pm
Diego,
I’m not sure what all of the possible responses are. Hopefully someone who has seen more then a “1″ will let us know what values they have encountered and what they mean.
December 11th, 2023 at 12:02 pm
Jim,
Thanks for the great info on ARB and the very useful API…
On the Silent Post feature, do you know what fields are returned in addition to x_subscription_id, x_subscription_paynum and x_subscription_id? I’m not seeing any detail on whether we get back any other transaction items (to help verify the authenticity of the request) but maybe I’m just missing an important doc somewhere?
Thanks…
December 11th, 2023 at 8:59 pm
Ted,
Here’s a list of all of the fields they return:
x_response_code
x_response_subcode
x_response_reason_code
x_response_reason_text
x_auth_code
x_avs_code
x_trans_id
x_invoice_num
x_description
x_amount
x_method
x_type
x_cust_id
x_first_name
x_last_name
x_company
x_address
x_city
x_state
x_zip
x_country
x_phone
x_fax
x_email
x_ship_to_first_name
x_ship_to_last_name
x_ship_to_company
x_ship_to_address
x_ship_to_city
x_ship_to_state
x_ship_to_zip
x_ship_to_country
x_tax
x_duty
x_freight
x_tax_exempt
x_po_num
x_MD5_Hash
x_cavv_response
x_test_request
x_subscription_id
x_subscription_paynum
December 11th, 2023 at 11:07 pm
Thanks Jim.
One more question… i see the AVS field in the return list but not in the API. I assume that’s simply there because this output is shared with other scripts? Or is AVS another undocumented feature?
December 17th, 2023 at 10:19 am
I appreciate this script very much. However, I do have one question. I assume the script is for parsing only one entry that was returned by silent URL, correct?
I have an application that will be getting multiple payments each day. So what I want to do is check each one that is returned by silent URL and if it was successful, I need to update the expiration date in my database where the initial subscriptionID is stored.
Since I can’t really test this script because I am in test mode, can you please tell me if I have done this correctly in the script below?
I’ve moved the sending of emails and updating of database within the foreach loop. I then am not sure if this is the correct way to check the subscriptionID value.
// 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
…
}
if ($arb == true && $fields[’x_response_code’] == 1)
{
//The APB transaction equals 1 (or OK) so update expire date in database now
$subscriptionID = $fields[’x_subscription_id’]; //is this correct???
$expireDate is configured here……….
$updatequery = sprintf
(”UPDATE listing SET expireDate =’%s’ WHERE subscriptionID = $subscriptionID”,
quote_for_safety($expireDate)
);
mysql_query($updatequery);
}
}//end foreach
January 12th, 2024 at 9:59 am
If an ARB transaction has been working fine but then fails because the credit card is expired is there a way to correct the expiration date and rerun the failed transaction.