<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Handling Authorize.Net ARB Subscription Failures</title>
	<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/</link>
	<description>A blog about merchant accounts and merchant services</description>
	<pubDate>Wed, 08 Oct 2008 04:04:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0</generator>

	<item>
		<title>by: Russell H.</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18146</link>
		<pubDate>Sun, 28 Sep 2008 16:14:26 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18146</guid>
					<description>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:

&quot;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.&quot;

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.</description>
		<content:encoded><![CDATA[<p>Useful information.  I had read about Silent Post before, and I&#8217;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&#8230;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.</p>
<p>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:</p>
<p>&#8220;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.&#8221;</p>
<p>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.  </p>
<p>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:</p>
<p>Credit card # or expiration date expired<br />
gateway was in test mode at time of scheduled payment<br />
eCheck.net disabled<br />
NOC (notification of change) for eCheck received</p>
<p>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&#8217;m not sure how to get around that issue automatically.  But other declines do send notification - I&#8217;m sure.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Sagar R</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18140</link>
		<pubDate>Sat, 06 Sep 2008 03:48:41 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18140</guid>
					<description>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 ..</description>
		<content:encoded><![CDATA[<p>Hi John, </p>
<p>Thanks for the valuable reply,</p>
<p>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 &#8216;Silent URL&#8217; 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 !</p>
<p> 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 !)</p>
<p>Anyways , Thanks for the help ! I`m gonna tell my Boss that we need  one real merchant account now ..
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: John Conde</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18139</link>
		<pubDate>Fri, 05 Sep 2008 18:26:52 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18139</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Sagar,</p>
<p>I haven&#8217;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&#8217;s great. If not, maybe you can try it out on your first ARB client.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Sagar R</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18138</link>
		<pubDate>Fri, 05 Sep 2008 09:46:23 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18138</guid>
					<description>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 ??</description>
		<content:encoded><![CDATA[<p>Hi Jhon, </p>
<p>Just a silly doubt , </p>
<p>Is Authnet provide Silent Post functionality in in test account i.e &#8216;https://test.authorize.net/ &#8216; , 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 ??
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: John Conde</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18136</link>
		<pubDate>Thu, 04 Sep 2008 12:52:54 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18136</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Chirayu,</p>
<p>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&#8217;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&#8217;s history of their their recurring billing payments.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: chirayu</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18135</link>
		<pubDate>Thu, 04 Sep 2008 03:40:22 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18135</guid>
					<description>Hi John,
 
Thanks for the information about the Silent Post URL for ARB subscription. 
 
There is one question related to use of &quot;Silent Post URL&quot; 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</description>
		<content:encoded><![CDATA[<p>Hi John,</p>
<p>Thanks for the information about the Silent Post URL for ARB subscription. </p>
<p>There is one question related to use of &#8220;Silent Post URL&#8221; for which I am searching for an answer. I feel or rather believe that you might be having the answer to that.</p>
<p>Let me put the scenario, for which I am finding solution, in front of you:</p>
<p>I am presently working on one of my client&#8217;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.</p>
<p>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. </p>
<p>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.</p>
<p>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. </p>
<p>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. </p>
<p>Please help me in finding the answer to this question.</p>
<p>Thanks in advance.</p>
<p>Best Regards,</p>
<p>Chirayu Tailor
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Jim H</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18133</link>
		<pubDate>Thu, 04 Sep 2008 02:23:55 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18133</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>I would like to add the following facts and opinions&#8230;</p>
<p>1) silent post was unknown to me<br />
2) your tutorials are more helpful than anything AuthNet has out there<br />
3) John H may be a newbie; however, he is very experienced at being a douche bag.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Flip</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18128</link>
		<pubDate>Tue, 02 Sep 2008 21:06:23 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18128</guid>
					<description>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!</description>
		<content:encoded><![CDATA[<p>Props on your response to Jon H.&#8211;very funny, what a boner&#8230;  Thanks also for your info on the Silent Post&#8211;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!
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Dan Grossman</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18014</link>
		<pubDate>Wed, 16 Jul 2008 14:18:11 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-18014</guid>
					<description>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 :)</description>
		<content:encoded><![CDATA[<p>I should really visit this blog more often. You&#8217;re amazing. I don&#8217;t know how I never came across this either&#8230; it&#8217;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 :)
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: John Conde</title>
		<link>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-17970</link>
		<pubDate>Wed, 09 Jul 2008 22:26:34 +0000</pubDate>
		<guid>http://www.merchant-account-services.org/blog/handling-authorizenet-arb-subscription-failures/#comment-17970</guid>
					<description>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.</description>
		<content:encoded><![CDATA[<p>Since you took a very negative tone in your comment I will have fun embarrassing you. </p>
<p>Firstly, I have twice as much experience as you in this arena so I don&#8217;t recommend trying to sound special by saying you&#8217;ve been doing this for 5 years. You just sound like a newbie.</p>
<p>Secondly, if you had bothered to read this blog post you would have noticed we&#8217;re talking about using the silent post feature for Authnet&#8217;s ARB service. Not their AIM service. It&#8217;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.</p>
<p>Thirdly, there is a solution for handling declined transactions: they&#8217;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.</p>
<p>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&#8217;s services.</p>
<p>Oh, and thank you for the laugh.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
