topic Re: ARB subscription problem in Integration and Testing

ARB subscription problem

Ashish — Mon, 01 Feb 2010 04:06:21 GMT

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

Re: ARB subscription problem

itdevworks — Mon, 01 Feb 2010 05:45:00 GMT

ARB Subscriptions do not actually generate transactions on a Test account. The Test server just lets you make sure your calls to ARB are successful.

Re: ARB subscription problem

Ashish — Mon, 01 Feb 2010 06:36:03 GMT

Thanks for the reply.

"ARB Subscriptions do not actually generate transactions on a Test account. The Test server just lets you make sure your calls to ARB are successful."

means if i want to test the ARB subscription on Test account then it is onto possible. am i right?

or there is any way to test the ARB transaction?

and as you said "The Test server just lets you make sure your calls to ARB are successful." means the test server only gives notification to subscription created or not , but it don't give any response regarding transaction of ARB done or not?

am i right?

is there any way to check that the ARB transactions are happening in Test account?

Thanks,

Ashish

Re: ARB subscription problem

stymiee — Mon, 01 Feb 2010 14:13:30 GMT

The purpose of the test account is to allow a developer to verify their API calls are correct. Not to actually establish subscriptions or process credit cards. If the test account is telling you that a transaction was successful then everything was done properly. There's no need to actually establish a subscription as it really offers nothing to the developer.

Re: ARB subscription problem

Ashish — Tue, 02 Feb 2010 05:01:06 GMT

Thank you for the kind response.

i really got what you explain.

but still i am curious about that

(1) in ARB, i have created the subscriptions successfully at Test account .

then in the Test account the transactions from the subscriptions will occur or not?

i have put 7 days period for recurring. as today is 9 th day .

(2) in Test account if i want to check weather the subscriptions make its transactions. then is it possible?

Thanks,

Ashish.

Re: ARB subscription problem

itdevworks — Tue, 02 Feb 2010 05:07:44 GMT

(1) in ARB, i have created the subscriptions successfully at Test account .

then in the Test account the transactions from the subscriptions will occur or not? - No. They will not.

i have put 7 days period for recurring. as today is 9 th day .

(2) in Test account if i want to check weather the subscriptions make its transactions. then is it possible? - No.

Re: ARB subscription problem

Ashish — Tue, 02 Feb 2010 05:25:45 GMT

I think I am not able to make things clear for you guys, for that I apologize.

Here is what we are actually trying to implement.

1) We are using the Test account.

2) User will come to our website and can select a subscription (recurring) or a one time payment.

3) In case of subscription, the user is charged first time when he completes the checkout process and if the AIM response is positive we update our database but, at this same time we also create a ARB for the defined period of the subscription, which in this case is set to 7 days (for testing purpose). Now after this 7 days, user's card is again charged for the defined amount and we want a callback which can be used to update our local database. We understand that in this case we will receive the response similar to AIM.

Basically we are not able to receive the second callback, which is set to fire after 7 days of the first transaction.

I hope I was able to explain what we are looking for.

Thanks again for all your support.

Re: ARB subscription problem

soundcommerce — Tue, 02 Feb 2010 05:45:55 GMT

Why not use the trial amount and trial occurrence option to charge the user initially, then set the recurring date to +7 days (future date). This would eliminate the need to send two separate transactions to the gateway.

Thanks!

Re: ARB subscription problem

stymiee — Tue, 02 Feb 2010 12:47:43 GMT

IF YOU ARE USING THE TEST ACCOUNT NO SUBSCRIPTION WILL BE CREATED. An actual working subscriotion is only created when you use a live account.

Re: ARB subscription problem

stymiee — Tue, 02 Feb 2010 12:48:57 GMT

@soundcommerce wrote:
Why not use the trial amount and trial occurrence option to charge the user initially, then set the recurring date to +7 days (future date). This would eliminate the need to send two separate transactions to the gateway.

Thanks!

Because that's a bad practice. If the credit card is bad you won't know until the bext day and the customer is long gone. If you use AIM to charge the first payment you'll know immediately that the card is no good and you can request a new credit card while the customer is still present.

Re: ARB subscription problem

soundcommerce — Tue, 02 Feb 2010 14:03:42 GMT

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!

Re: ARB subscription problem

stymiee — Tue, 02 Feb 2010 14:27:27 GMT

@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.

Re: ARB subscription problem

soundcommerce — Tue, 02 Feb 2010 14:37:22 GMT

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!

Re: ARB subscription problem

stymiee — Tue, 02 Feb 2010 14:39:46 GMT

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.

Re: ARB subscription problem

soundcommerce — Tue, 02 Feb 2010 14:42:32 GMT

I agree :)

Re: ARB subscription problem

Ashish — Sat, 06 Feb 2010 11:20:38 GMT

Thank you stymiee for your kind responses.

Thank you soundcommerce for your kind responses.

Now i got the right direction.

Thanks & Regards,

Ashish.

Re: ARB subscription problem

soundcommerce — Sat, 06 Feb 2010 16:28:52 GMT

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

Thank You!

Re: ARB subscription problem

sanspriya84 — Fri, 05 Mar 2010 07:12:42 GMT

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.

Re: ARB subscription problem

stymiee — Fri, 05 Mar 2010 14:27:52 GMT

@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.

Re: ARB subscription problem

itdevworks — Fri, 05 Mar 2010 14:37:51 GMT

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.