ARB: Auto Re-Attempt after Suspended Status

[robertjmoore]

I am having trouble understanding specifically when Authorize.net attempts to automatically re-attempt to charge an ARB payment that has failed.

Below I list the facts that I know to be true based on the documentation and forums, followed by my specific question.

What I know to be true:

-An ARB subscription is placed into SUSPENDED status whenever the first attempt at charging a specific card fails.  This can be either the first payment of a subscription OR the first payment attempt after the card information for an existing subscription has been changed to a new card.

-If a payment that is not the first ARB payment on a given card fails (i.e. that card has been successfully charged by ARB in the past), the subscription will remain in ACTIVE status and Authorize.net will not re-attempt the subscription payment.  It will simply skip that payment and try the card again on the next scheduled payment date of the subscription.

-Any time a customer who is in SUSPENDED status updates their credit card information (ie using an  ARBUpdateSubscriptionRequest), they are automatically placed back into ACTIVE status.

-Sometimes, after a customer who is in SUSPENDED status updates his card information and is placed back into ACTIVE status, Auth.net will try to charge that subscription payment again at 2AM the following morning.

What's Unclear:

-According to some forum posts (http://community.developer.authorize.net/t5/Integration-and-Testing/ARB-no-silent-post-on-subscripti...), ARB will attempt to automatically re-try a failed subscription payment anytime a subscription goes from SUSPENDED to ACTIVE as a result of a customer's payment information being updated.  This would suggest that any payment (whether it's the first or the fifth) will be re-attempted as long as the transition from SUSPENDED to ACTIVE has taken place.

-According to other forum posts (http://community.developer.authorize.net/t5/Integration-and-Testing/Reactivate-Suspended-Suscription...), the attempt to re-try a failed subscription payment will only take place if the status goes from suspended to active AND if the ARB payment that failed was the FIRST payment on the subscription.  If this is true, then if a customer updated his card after a successful payment #4, the new card failed when trying payment #5 (placing them into suspended status), then the customer updated his info with a valid card (placing him back into active status), the missed fifth payment would not be automatically re-tried.

So, to summarize my question, under what exact circumstances does Authorize.net attempt to charge a failed ARB subscription a second time?

[TJPride]

FAILS ON FIRST PAYMENT

- Suspended

- Updates cause it to start billing on the next cycle, but not rebill for the failed payment.

FAILS ON ANY SUBSEQUENT PAYMENT

- Not suspended

- Will continue billing on schedule (not sure if it picks up the missing payment, however?)

FAILS ON SUBSEQUENT PAYMENT RIGHT AFTER CREDIT CARD UPDATE

- See FAILS ON FIRST PAYMENT

Unless you've already integrated this heavily into your programming, my advice is to switch to CIM and save yourself a lot of hassle. CIM combines the ability to do recurring billing (using an automated process on your end) with the ease of use of AIM (since you can submit a charge, get back a response, and act accordingly).

[robertjmoore]

If this is accurate, then it never "tries again" after a card is updated?

This is contradictory to what was said by Admin Michelle here: " If you update the billing information on a suspended subscription, the payment gateway will automatically try and process the missed payment. But it will not do that on an active subscription. For an active subscription, you must update the billing information, but then you must also get the customer's information to run a catch up transaction."

Am I misunderstanding or is she incorrect?

[TJPride]

Hmm, Michelle is contradicting her own earlier post, then. I guess the only way to find out for sure is to test and see what happens. Honestly, CIM is going to be much more straightforward.

[qfuse2012]

Hi,

Did you ever get an answer to this? I had the same thing happen (a subscription failed as was put into a suspended state). This was because I updated their address incorrectly. Will authorize.net automatically try to re-process the payment since I have now updated the address information?

[Trevor]

First off, TJPride's description of what causes a "suspended" status is correct.  However, there is still some difference in what happens when you reactivate a suspended subscription.  If the subscription was suspended on the first payment, then you are asked to enter a new start date when you update the payment details.  In this case, the subscription will start on this new date and no payments are missed.

If an ongoing subscription is suspended after the payment details are entered, then it is not possible to change the subscription timetable.  Under these circumstances, there will not be an attempt to make up the missed transaction.

[shkkmo]

" If the subscription was suspended on the first payment, then you are asked to enter a new start date when you update the payment details.  In this case, the subscription will start on this new date and no payments are missed."

How does this apply to ARB profiles that have been updated using the 'ARBUpdateSubscriptionRequest' API method if no new start date is passed?

Specifically I'm worried about the behavior of a particular edge case:

Setup a ARB on 1/1/2013 with:

start date: 2/1/2013

interval: month

On 2/1/2013 the Authorize.net attempts to bill the first payement fails. This causes the ARB profile to be suspended.

On 3/15/2013 the customer visits our website and updates their billing information. We fire off an  'ARBUpdateSubscriptionRequest', to updates the customer's ARB.

If no Start Date is included in the  'ARBUpdateSubscriptionRequest', what happens at this point?

Does Authorize.net attempt to bill for the 2/1/2013 payement and the 3/1/2013 payment?

Does Authorize.net only automatically bill for one payment?

Does the Start Date ever get updated by a 'ARBUpdateSubscriptionRequest' if no Start Date is passed in the request?

I can't find any documentation of this behavior and your help would be greatly appreciated.

[RaynorC1emen7]

If I remember it correctly, it will NOT bill the previous attempt, it will only start on the next schedule one. On your case, it would be 4/1/2013

[shkkmo]

"If I remember it correctly, it will NOT bill the previous attempt, it will only start on the next schedule one. On your case, it would be 4/1/2013"

Thank you for your response, but incorrect guesses are not helpful. You might need to re-read the thread more carefully.

In my edge case, if the customer were to have upated their billing infomation on 2/15/2013, Auth.net would have billed them at 2am on 2/16/2013. This is established behavior and not in question. Why would delaying the update of the billing informaiton cause the first payment to not automatically be charged?

[shkkmo]

I called Authorize.net and have the answer to my question.

My edge case is moot because suspended accounts are automatically cancelled 30 days after they are suspended.

However, it is important to note that any updates to an ARB that involves credit card information, followed by a filed payment can cause a subscription to be suspended.

For this reason, it is important to always call 'ARBGetSubscriptionStatus' at some point so you know if the customer will be auto-charged (and can pick up the slack if not). This can be done either after a tranaction error is sent to the SilentPost listener to update your local record of the subscription status, or before calling 'ARBUpdateSubscriptionRequest', to determine if the customer will be automatically charged the next day because of the update.