Doubt in About setting ARB Subscription Start date relating to different Time zone and ARB update.

[sanspriya84]

  Hello All,

                We are using AIM & ARB in our web application. I've doubts in assigning subscription start date. Please clarify me the doubts and apologize me if I've put forth some ignorant questions.

1. While setting ARB subscription start date, should I have to convert the user time zone date to PST or set the User Time zone date / UTC time ?. But I tested this with several combinations of date/time and Time zone and converted to PST date. The actual user Timezone date and PST date shows no variation in date except variations in time.( In other words, will Time Zone differences affect subscription start date? (i.e.) the date the transaction is triggered in NET.)

2. We are setting subscription dates such that the next subscription Start date is the next day to the previous subscription End Date. When the first transaction of the Create Subscription request fails, (i.e Transaction next to the AIM ), then we'll obtain the response through silent post, that the transaction was not successful. So depending on the response, we can mail the user, that the transaction was not successful and needs it to be updated. By the time the user might have their previous subscription expired and till the time he updates with new details, there will be a Gap for the user in using the service provided to the user (i.e access to some premium pages of our site in our case). Is there any work around to solve this issue.

3. While updating the subscription request, (I.e Update after transaction decline) is it a better solution to use AIM to create a new subscription and continue the subsequent subscriptions with ARB and cancel the previous create subscription request. Why I've to choose for this method is when I let the user to update by using the update subscription request, then I may not be able to check AVS/CCV in real time. With the above conception then there arises a doubt in what scenarios the update subsequent request can be used.

4. If the user chooses for yearly subscription, the first year subscription is through AIM and is successful and the create subsequent request is sent along for next year. Before the next subscription transaction is triggered, the user may want to update his details. If we allow the user to update, I should have to check for AVS & CCV. Should I have to accomplish this by setting x_type as AUTH_ONLY and amount with $0.01 and create AIM transaction and enable ARB. Is there any other work around for this issue.

5. When the user updates many times, since call to Authorization.net is made every time for checking AVS and CCV, will the merchant be charged for every check.

 Thanks

 Priya.

[stymiee · Accepted solution]

1. The time zone doesn't matter as all subscriptions are processed at the same time every day. All you need to do is make sure you get the date right.

2. If a subscription fails it is up to you to collect that payment, most likely via AIM. Then once you update the subscription again it will resume and process future payments as normal. As of now this is how the system works with no changes expected any time soon.

3. Continuing with the above answer, since you are using AIM to capture the missed payment it naturally is the perfect time to verify AVS and CVV.

4. You should do an AUTH_ONLY for $0.00 unless your processor does not support it. Then you should do it for $0.01 and VOID the transaction when completed. That is your only option to verify the card before updating the subscription.

5. Correct.

[sanspriya84]

Thank you very much. The explanation has cleared my doubts and is really great.

Thanks

Priya.

[sanspriya84]

Hello All,
   Our requirement is that all the ARB transaction should start on the same day every year.
 I'm elaborating my doubt by putting a scenario,
Scenario :-
   1. We have set the interval 12 and unit month.
   2 Initial  AIM  request - which is  a success  March 26 2010 - March 25 2011.
   3. ARB Create request is also sent along  with setting  the subscription start date to Feb 26, 2011.

   We want a user to be paid for a ARB subscription for the period March 26 2011 - March 25 2012.
We set the subscription start date to Feb. 26, 2011 (1 month prior), so that if the transaction has failed for some
reason, the user can have enough time to update.An ARB  create request is created on Feb. 26, 2011.
and a response for the request is received with a subscription id. By next day, the response for
the transaction is failed and we notify the user to update the details correctly.
If the user updates on Feb. 28,2011. By the time of the subscription update request is sent, we change the start date to
Feb. 28, 2011 and send.
    Hence the subscription start date is changed for the subscription,  will the subsequent subscriptions trigger on every year
Feb. 28.  However we actually want the subsequent subscription to be triggered on Feb. 26 the same year as we've set it in the Initial ARB Create request.

 This problem will be solved if I cancel a declined ARB and create an AIM immediately
(As I have mentioned in the above post).But Is it a Industry recommended practice to cancel the subscription
and create an AIM after the ARB is declined.Our Manager has some speculation on implementing the method by
canceling a ARB and Creating an AIM-AUTH_CAPTURE when a ARB transaction is failed.
Does this actually incorrect following this method? Please let me know this is a recommended method.
Which method would you follow if this condition arises? Any recommendation is greatly appreciated.

Another doubt about subscription start date validation :-  
     In conditions, where we change the Subscription start date in ARB updateRequest, will the start be
validated against the date the subscription was created or against the date the subscription is updated. 

Thanks
Priya

[stymiee]

Don't set the first subscription payment to be one month before you really want their subscription to start. You don't accomplish anything by doing that. Set the first payment date to be March 26, 2010. If it fails you'll use AIM to collect the money instead. Then you can update the ARB record so that next year the payment (theoretically) will not fail. Having it run a month sooner accomplishes nothing because as soon as the subscription payment fails it will not be charged again until you update the subscription and then it still won't charge them again until their next scheduled payment which is next year.

[klempit]

Hello, I am hoping someone can clarify something for us.  HomeESP is a membership club (think AAA for homeowners).  We charge a monthly membership fee.  When an ARB fails for reason 2 (general decline), we have been manually changing the start date for the sub to be a few business days ahead of the failed attempt, in an effort to "recycle" the credit card and have ARB attempt to charge the card when a consumer payment may have been made to reduce the account below its credit limit.  I've got two questions related to this process.

1 - is this a valid method to handle cards which decline with reason code 2, and if they succeed with the new start date does the subscription go on as usual with (in our case) monthly billing on the new day-of-month anniversary? 

2 - if the manual process outlined above is a valid method to deal with cards which decline, can I update subscriptions via the API to accomplish the same (would be much better than manually trying to keep up with all this)?

Thank you in advance for any assistance.

Ken

[TJPride]

In answer to the OP's question about the gap in service, I would think that has to do more with your access rules giving an extra 3 days (or whatever) of leeway beyond the expiration date, rather than just cutting off on the exact second the account expires. You want some hours of leeway anyway, because the cards aren't charged on the first second of the first hour of the day, so adding another couple days won't kill anything.

[Trevor]

It is perfectly acceptable to just try and restart the subscription again if you don't want to try and update card information first. In the circumstances that the first transaction fails and you then change the start date, the subscription will run as if that first transaction was never attempted.  Any update that you make to a subscription through the online interface can also be made programmatically using an ARBUpdateSubscriptionRequest.