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.

[RichardH]

Hello @alippert 

I would encourage you to post this as a new feature using our Ideas forum. This will allow others to vote on and make suggestions to improve the request.

Richard

[paul_westpier]

---

@RichardH wrote:

Hello @alippert 

I would encourage you to post this as a new feature using our Ideas forum. This will allow others to vote on and make suggestions to improve the request.

Richard

---

Richard

With all due respect, that's a lame response at best, and a brush-off at worst.

On 05-16-2014 @08:30 AM you wrote:

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

So, that turned out not to be the case after all? Or the "product team" discussed it and decided it wasn't worth implementing, and just forgot to mention it to everyone here?

I think your product team has a lot of work to do in communicating its intent, plans, activities and outcomes to its users.

Regards

Paul

[paul_westpier]

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

So, that turned out not to be the case after all? Or the "product team" discussed it and decided it wasn't worth implementing, and just forgot to mention it to everyone here?

I think your product team has a lot of work to do in communicating its intent, plans, activities and outcomes to its users.

Regards

Paul

[alippert]

The fundamental flaws in the Authorize.net architecture continue....

Knowing that the arbitrary values of subscription status could trip up the unsuspecting, we implemented a process to capture the change in status of recurring billing transactions using the daily Summary of Automated Recurring Billing email provided by Auth.net. Sadly, this too is a flawed implementation as sending of the email is not guaranteed by Authorize.net. So, if you do not receive an email with failed transactions, you do not know that a customer is due to be notified, that you've missed a payment on a transaciton, that a subscription remains in the Active status, and that you won't be notified until the next biling cycle (quarterly in our case).

As a developer, you are totally screwed at this point with absolutely no relief in site from the development staff at Authorize.net who has known about these fundamental flaws since inception and has elected to do absolutely nothing to fix their system.

You can't depend on the Silent Post as delivery is not guaranteed, the daily summary email as delivery is not guaranteed, or the current status of the subscription in the Auth.net system as the status reports active after a tranaction failure with no way to query last transaction status - period.

Contact Customer Service and you'll be promised that they will add enhanced reporting to the feature request list. Laughable. How long has this thread been open, let alone the feature requests to rationalize a flawed architecture? The service is flawed by design, broken in the implementation, and provides absolutely no way to fully automate the handling of recurring transactions. Forewarned is forearmed. If you want to build a commercial grade service - look elsewhere.

[RaynorC1emen7]

The best way is to do your own schedule job with CIM, then you control how it flow.

[alippert]

Raynor,

I must humbly beg to differ with you. Authorize.net KNOWS about this issue. They have known about this issue for years. They SHOULD fix the problem ASAP. A consistent treatment of ALL failed recurring transactions would resolve the issue immediately. If a transaction fails, set the subscription to SUSPENDED. If a subsequent payment method update succeeds, trigger a catch up transaction and set status to ACTIVE. The fix is so obviously simple. Tthat it hasn't been implmented is criminal.

Customers switching to CIM and managing their own scheduling is not a viable response to Auth.net fixing a known flaw in the ARB service. Fixing the flaw quickly would be the appropriate response. We've now seen NO appropriate response from Authorize.net for more than 4 YEARS! Simply incredible.

[RaynorC1emen7]

But now they have many active ARB users, they can't just change the flow, they might break someone workaround that already in place.

[alippert]

The workarounds would still continue to work as the conditions mandating the workaround would never be triggered. Consistent handling of the currently deployed process based on the state of the subscription being SUSPENDED must already be managed in customer processes. So, no additional work for developers ought be required.

AND, they have had YEARS to get this fixed. It is LONG past time that they actually respond and do something about this particular issue.

As I have previously outlined. NO existing workaround is certain to function properly as the service deployed by Auth.net makes it impossible. You cannot depend on the reported subscription state, you can't depend on the silent response method to notify of transaction failure, nor can you depend on their daily summary of transactions to determine state. It is simply IMPOSSIBLE to build a reliable system given the currently deployed service. No one should believe that their current workarounds actually work. The service is fundamentally broken. So, Authorize.net has absolutely no excuse for not fixing it.

[brianmc]

Hi guys,

Brian here, I'm the product manager for API & Developer Experience (yes it's a new position) and firstly I want to say that I understand your frustration and we are aware of the issues around ARB.    I am also aware that nothing has been done to address those issues in many years.  I hope some of these recent changes (last 9 months) demonstrate that the developer is back in focus for Authorize.Net:

• Added Subscription ID to our transaction reporting (no more silent post or email parsing -http://developer.authorize.net/api/reference/index.html#transaction-reporting-get-transaction-list)
• Added GetSubscriptionList method (for parity with the UI - http://developer.authorize.net/api/reference/index.html#recurring-billing-get-a-list-of-subscription...
• Made CIM profiles fully interoperable with AIM CreateTransaction (various new and updated methods.

 I cannot promise that this specific issue will be fixed in the next few days or weeks (if there is a simple fix we will do it) but I can assure you that we are right in the middle of a sustained and prioritised effort to make our card-on-file services the very best they can be.  Decline consistency is a priority for us, but to build a better ARB we need to fundamentally update how it works;  teams are working on that today.   I can tell you that CIM profiles will be fully interoperable with ARB (our single biggest developer request over last 5 years) and ARB will be focused solely on scheduling & transaction workflow.

Signing off (for now) I can tell you that I want to embrace the feedback in this thread, in these forums, not ignore it.  If you ever want to give me feedback directly email developer@authorize.net and ask for me by name, I'm happy to correspond directly on any issue, idea or flat-out rant.

Sincerely,

Brian

[GeorgeBT]

It's been 6 months since the last post. I'm new to ARB and was curious if the problems presented here have been fixed yet. I haven't found any information to say that it has been fixed.

[rev23dev]

it's so frustrating this hasn't been addressed.

our user’s software will deactivate if their ARB payment fails. we give them a way to come to our site to reconcile the payment to immediately reactive their software. we take that payment then update the sub in ARB to reactivate it. guess what? they get billed again the next day. then we have to go refund that second payment.

what are we supposed to do in this situation? how has this not been addressed yet after all these years? shameful.

from the developer point of view this is just ridiculous to handle. check the status on the server, if suspended AND the first payment that failed just do an authonly for a $1.00 or something and hope it succeeds tomorrow? doesn't it auto terminate sometimes if the first payment declines too?