ARB subscription problem

[Ashish]

i am using test account.

i have successfully implemented ARB and able to create subscriptions.

i have created one subscription for 7 days recuring.

but now the 9 day of that subscription but still the transaction not created from that subscription.

can you please help me here, i want to test ARB in test account first.

Thanks,

Ashish

[soundcommerce]

John,

I would have to disagree with your statement. It's not a matter of bad practice, is purely preference. I'm sure the engineering team at Authorize.Net had specific reasons for validating (verifying) the transaction at 2AM as opposed to an immediate auth verification.

We have clients that prefer ARB to handle the entire process, we also have clients that deliver real-time on-demand media that require immediate AIM verification.

Customer's are also subject to "per transaction fees" by validating each subscription before sending a second request to register the transaction at Authorize.Net.

In closing it's strictly a matter of preference, as a drop ship company would not need to perform an authorization in real-time.

Thanks!

[stymiee]

---

@soundcommerce wrote:

I would have to disagree with your statement. It's not a matter of bad practice, is purely preference. I'm sure the engineering team at Authorize.Net had specific reasons for validating (verifying) the transaction at 2AM as opposed to an immediate auth verification.

---

It definitely isn't a preference issue but a practice issue. Tell me why it is better to wait up to a full 24 hours to determine if a credit card is good when the customer is long gone when you can know immediately that the card is either good or bad and, if bad, have the customer provide a different credit card while they are still present on your website? If you wait that extra day to charge the first payment and the card is declined or otherwise bad you now have to have an employee hunt down the customer to try to get a new credit card. Besides the fact that your odds of success are much lower then if you catch it immediately but now you've increased your costs of doing business as you have to pay someone to do something you could have automated. Considering how easy it is to use both APIs, it's just a few lines of code, it's unwise just to use ARB especially under the guise of having just one API call versus two.

---

soundcommerce wrote:  

We have clients that prefer ARB to handle the entire process,

---

Do they really have any clue what ARB is or why one method is better then the other? That's the developer's job to know and to inform them of why using the wrong API a bad idea. And if you really do have clients that prefer it not only are they in the minority (how many clients know about how Authnet works much less the nuances of how to use their APIs?) but that doesn't make it a good idea. I'd go so far as to say this is a case of a client that thinks they know more then they do and should be leaving things like this up to the developer.

---

soundcommerce wrote:  

Customer's are also subject to "per transaction fees" by validating each subscription before sending a second request to register the transaction at Authorize.Net.

---

There is no extra transaction fee for using AIM to charge the initial payment and then setting up an ARB subscription. The AIM transaction would incur a transaction fee as is appropriate (after all it is an actual transaction). But establishing the ARB subscription is free of charge. Fees are only incurred when a subscription is processed and the credit card is actually charged. If your clients are being charged for establishing subscriptions then something is very wrong somewhere.

---

@soundcommerce wrote:

In closing it's strictly a matter of preference, as a drop ship company would not need to perform an authorization in real-time.

---

A drop shipping company also most likely won't be using subscriptions. They'll be using either AIM or CIM.

But a website that has memberships will be using ARB and they'll want to use AIM to charge the first payment because if they didn't they would be giving members access to their content before confirming that they have a valid membership. Then when their credit card was declined later that night they could cancel the membership but that member already had access to their content and may have gotten everything they wanted from it. That's just bad business.

[soundcommerce]

John,

Let's focus on getting the issue resolved as opposed to debating best practices please.

Ashish,

Were you able to find a fix yet?

Thanks!

[stymiee]

I wonder if this software allows posts to split into their own thread? This is exactly the kind of discussion that would be great for other developers to read and learn from.

[soundcommerce]

I agree :)

[Ashish]

Thank you stymiee for your kind responses.

Thank you soundcommerce for your kind responses.

Now i got the right direction.

Thanks & Regards,

Ashish.

[soundcommerce]

If I may ask Ashish, what was the final resolution?

Thank You!

[sanspriya84]

Hello all,

          After all studying  the previous threads, I still have some doubts. I'm summarizing it below

 Our requirement is
           We're testing ARB using developer test account.
         1. First the user is made to pay initial amount of 10$ for 1 year. (This is done through AIM)
         2. The user should be given the provision for enabling the recurring subscriptions for 1 year  with 12 $.(For testing purpose, I used 7 days.) - should be done using ARB.
 
   I understand from the previous threads, it isn't possible to test the above scenario using test account.
But  I'm not clear how will we receive the response of the transactions even in live account.

 In AIM we are able to get the response for the requests then and there and hence we are able to make it. But in ARB once we create a request, if everything in the request is OK, we are getting a response XML with resulting code 'OK' saying the creation of the subscription was a success. But after, while at the time when  payment  for the transaction is done, either if there isn't enough amount for the transaction in the user's credit card or some other error prevails, the transaction will be declined. How will we receive these responses? Will it be received
through CSV files or by some means. I'm not clear about this scenario. I also studied from the document, the response can be received by appropriately setting the  Silent post URL in the merchant interface. Could anyone please shed some light.

Thanks
Priya.

[stymiee]

---

@sanspriya84 wrote:

But after, while at the time when  payment  for the transaction is done, either if there isn't enough amount for the transaction in the user's credit card or some other error prevails, the transaction will be declined. How will we receive these responses? Will it be received through CSV files or by some means. I'm not clear about this scenario. I also studied from the document, the response can be received by appropriately setting the  Silent post URL in the merchant interface. Could anyone please shed some light.

---

If you have set up Silent Post in your Merchant Interface any time a transaction is processed, regardless of the means, the result will be posted to Silent Post. So if a subscription payment is declined you will be notified via Silent Post immediately.

[itdevworks]

There are two ways to capture the information for transactions submitted via ARB subscriptions.  One is, as you said, via the SilentPost URL feature.  The other, as you also surmised, is from CSV files, in this case received via email.  I will explain each:

• SilentPost URL – The SilentPost URL is a feature of Authorize.Net where you can log in to your Authorize.Net account and in the Settings area, provide a URL that will be used to notify you of every transaction submitted to your account.  When a transaction request comes in, Authorize.Net will make an HTTP(S) POST request to the URL you specified, with all of the transaction response fields accessible via form fields.  In the case of ARB generated transactions, there are extra fields available which contain the subscriptionId, payment x of y, and some other data so you can programmatically distinguish normal single payments from recurring subscription payments.  It is important to note, though, that the request submitted to the SilentPost URL you provide is done so asynchronously, which is to say they send it and forget it, not waiting for any acknowledgement of receipt from your server.  Because of this, if the URL cannot be reached for some reason (server offline, server configuration changed, etc.), then the notification is lost.  Data obtained via SilentPost URL, therefore, should not be considered 100% reliable.  Another important issue is that the ARB service detects expired credit cards from their expiration date and never even tries to process them.  Because of this you will never get a SilentPost call for an expired credit card.

• CSV Files - If you log in to your Authorize.Net account (and your account has the proper permissions), then click on the User Administration link second from the bottom on the left, and select a user (your own account or anyone else's), down towards the bottom of the page is "Automated Recurring Billing (ARB) Emails" section.  Here you can check which of the seven available ARB notification emails are sent.  For whichever one you do, if there is any activity related to that category that day, you will receive an email with a .CSV file attached containing the summary of that activity for the day.  If you create a special email account just for receiving these notifications, you can create a program which checks the inbox for that account, grabs any emails, extracts the attachment and processes the CSV file.  Then schedule the program to run once per day on whatever machine is available for such a job (using Scheduled Tasks in Windows or a cron job in *nix).

The CSV file processing is clearly more reliable since the emails will be queued, even if your server where the processing program runs goes offline for a bit, but you could also implement both if you want more fault tolerance.