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.

[rev23dev]

Yes, this exactly.

It all boils down to there is no consistency in the handling of suspended subscriptions. Trying to use ARB as a SaaS payment solution is really lacking because you can't just leave it alone. Too many branches of code to handle separate situations.

If a payment declines, suspend the subscription. Let us take a manual payment and apply it to the subscription so when it is reactivated it doesn't attempt to charge the card again the next day (the biggest problem). If the subscription is suspended through its next payment cycle just terminate it.

[brianmc]

We're a couple of months out from some great new features for subscriptions and trust me the initial/subsequent retry is top of the list for being fixed.  That being said, for @kos the fact that Subscriptions is now built on top of Customer Profiles might help you out in the short term. If you fail a subscription just make a GetSubscription API call, get the customer profile and charge that profile for the subscription amount.  We have just released a new reporting method GetTransactionListForCustomer but unfortunately right now it's only returning profile transactions so you will see those ad-hoc transactions but not the full subscription transaction history.  Again the new Subscriptions API will have a GetSubscription that returns all that good stuff like failed transactions, reasons, retry API call, etc.  It's coming soon, I can promise you that.

Brian

[brianmc]

It's been so long overdue but we're finally getting close to the first of many releases which constitute a major overhaul of our recurring billing features.  As per this thread we didn't want to make a single other change until we had fixed the decline/retry behaviour.  Here's the logic we're planning to deliver in the initial release, we'd really appreciate any feedback, comments, concerns you may have. 

1. A new retry schedule will be introduced that will activate on any failed charge, either initial or subsequent occurrence.  [initial default schedule not finalized but will be configurable in future releases]
2. Failed subscriptions will move to suspended only after the retry schedule has been exhausted (so imagine something like 5 retries on 1 hr, 12 hrs, 24hrs, 2 days, 3 days).
3. Email template for failed subscriptions will be updated to articulate that the charge has failed and it will be retried (at mm/dd/yy hh:mm).  This will be sent out for every failed retry.
4. Initial and Subsequent charges have this EXACT SAME workflow.

In follow-on releases we will have a new API, better reporting of subscription history, succssful & failed transactions, plan management and lots more.

[rev23dev]

Hi Brian,

What about terminations? When an ARB subscription automatically terminate itself (if at all anymore?)

[rev23dev]

Also, the emails that go out. Can we turn those off? I deal with that internally in my system because I like richer content in my emails. Authnet emails that send now are... ugly ;)

[brianmc]

Right now we're not sure how useful the terminated state really is for merchants.  You can't bring it back from that state and it seems like if it really is no longer used or the card information canot be updated then it should probably be up to the merchant to cancel the subscription.  What do you think?

[brianmc]

On the emails (they certainly aren't pretty :-), those can be turned off via the Merchant Interface by going to Account->User Profile->Edit Profile Information and unchecking the boxes under ARB Emails.

[rev23dev]

Yep. I agree on Terminated status.

It does kind of have its place, where if it declines like 6 months in a row, it may make sense to just terminate automatically, since we're paying authorization fees on those. But the way its handled now is not as useful.

[brianmc]

Blog post coming soon but just wanted to let this thread know that we released updates to ARB to sandbox yesterday and production will be updated today.  Essentially this provides a consistent retry across all occurrences and always puts the subscription into suspended status if a charge is declined.  To try the new retry you can go into the merchant interface ARB Settings section and opt in.

[rev23dev]

So you have to opt into this?

Once it goes to suspended, do you just need to update it and it tries again the following day?