ARB: Active vs Suspended STATUS on Decline?

[ayurvibes]

I've read several posts here on the behavior of ARB when a scheduled payment is DECLINED.

From what I gather - for an EXISTING ARB subscription WHEN PAYMENT IS DECLINED:

1. If it is the FIRST scheduled payment or payment info has been updated recenlty, the subscription STATUS gets set to SUSPENDED.

Updating payment info sets subscription STATUS back to ACTIVE and the NEXT DAY at 2AM there is another attempt to process, no matter when the next subscription payment should run.

2. If there has been 1 or more past payments on the subscription, the subscription STATUS *STAYS* ACTIVE.

Updating payment info does nothing to STATUS and the next payment attempt is not run until the next scheduled date (could be 30 days away for a monthly subscription).

How does one programatically deal with these two scenerios which are BOTH DECLINES but ARB is not consistent with STATUS or NEXT CHARGE DATE?

Here's the workflow:

1. From SILENT POST we know an ARB payment has failed (DECLINED).

2. Next, check subscription status via API could be ACTIVE or SUSPENDED depending on 1 & 2 above! NO LOGIC HERE!

3. If SUSPENDED, update payment, ARB runs again *NEXT DAY* a 2AM. At the time of update you won't know if card is valid, so possibility of failure. Could do AIM AUTH_ONLY to prevent this, but that's an extra step. Can't do AIM catch up here because ARB would double charge the user, since SUSPENDED updates automatically run the NEXT DAY at 2AM!

4. If ACTIVE, update payment, ARB won't run again until next scheduled DATE. Have to process AIM Catch up payment to get account current.

Seems like the only accurate way to deal with a SILENT POST ARB decline is to cancel the subscription, do an AIM catch up and create new ARB subscription. Relying on API subscription STATUS is not accurate.

STATUS SHOULD BE *SUSPENDED* IN EVERY CASE when payment is declined! And also, the next payment charge date should be consistent and not vary if STATUS is SUSPENDED or ACTIVE!

It's way too much headache to try and programmatically account for all the scenerios above. You would have to store another DB field for LAST_PAYMENT_STATUS (declined, accepted) alongside ARB_STATUS (active, suspended, etc). This is a waste. What is ARB STATUS useful for if not to know if the subscription is active or not. And when a payment FAILS there is no good reason for a subscription to stay ACTIVE!

Please post the solutions that you've found for these issues.

[TJPride]

Would be more helpful if it worked that way as well for subscriptions that have processed one or more payments. Any chance of adding a control panel setting that allows you to choose behavior?

-Ted

[Michelle]

Hey Ted,

I can certainly pass that suggestion on to our development teams. Can't give you any kinda quote on when or if that will be implemented, but I can tell you that they take feedback from the community very seriously.

Thanks,

Michelle

Developer Community Manager

[TechStu]

Is there times when the first payment can be declined and NOT go into suspended mode?  It seems that just happened in my developement environment but I thought if the first payment was declined the arb would always be suspended.  Please clarify, thanks.

*Edit: I am pretty sure that I did update the ARB with a new payment amount prior to the first payment.  Would that cause it not to go into suspended mode?

[Joy]

Hi TechStu,

It doesn't happen in normal circumstances,  if the first payment was decline then the subscription will go into suspended status, if you got a decline instead I suggest that you email developer@authorize.net if you have specific examples you would like more information on or you can also contact our Customer Service.

Thanks!

-Joy

[supercleanse]

This was posted 2 years agon now ... is this still the way ARB handles declines?

Is the AIM "catch-up" still necessary after the user's cc info is updated?

It would be very helpful if ARB is able to rebill within 24 hours after the user's credit card information is updated ...

Thanks,

Blair

[ptlapa]

This issue of ARB not able to handle declined credit cards until the next billing cycle is an absolute joke.

Are you kidding me?  Should we just give away a free month because you can't support your customers requirments?

And no, manually adding the corrected payment via your virtual terminal is no solution.  The history of the ARB is broken (as it takes too much effort to figure out what the result of the decline was on the account).

With all the millions of Target customers issued new credit cards this year, this liability is just too big. I am starting to seek out a 'better' solution.

This issue was raised way back in 2011....Shame on you for not listening to your customers.

[RichardH]

Hello @ptlapa 

We appreciate you raising this enhancement request again.  However, I can tell you that the product team is actively discussing this and other request to improve our recurring billing features through the API. 

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

[alippert]

Another 4 months on - updated status? We are about to tackle this problem and it would be REALLY helpful to have it funcitoning in a fashion that SUPPORTED development.

[healthsuccess]

Following

[alippert]

Another year - and this issue STILL lingers. To the Auth.net team - I am quite certain you have no concenption of exactly how onnerous this particular design choice makes things for your customers. Consistency of behavior - all declines mark subscription status as SUSPENDED. Any subsequent update to payment method tries the catch-up transaction - wuold make ALL of our lives very much easier. The current situation is literally indefensible. How about taking a few minutes and fixing this obvious design flaw.

Thanks