Reply
Posts: 2,248
Topics: 51
Kudos: 151
Blog Posts: 64
Registered: ‎12-05-2011

Re: ARB: Active vs Suspended STATUS on Decline?

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

--------

Webhooks are now available for Authorize.Net

Using SOAP, see our deprecation notice.
Check out Accept.js, our Javascript replacement for DPM.
Pro Tip: Never use test mode in the sandbox, instead use the Testing Guide.
Contributor
Posts: 12
Registered: ‎01-16-2014

Re: ARB: Active vs Suspended STATUS on Decline?


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.

 

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. 

 

 

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

 

 

 

Member
Posts: 5
Registered: ‎09-18-2014

Re: ARB: Active vs Suspended STATUS on Decline?

[ Edited ]

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.

Expert
Posts: 4,525
Registered: ‎03-08-2010

Re: ARB: Active vs Suspended STATUS on Decline?

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

Member
Posts: 5
Registered: ‎09-18-2014

Re: ARB: Active vs Suspended STATUS on Decline?

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.

Expert
Posts: 4,525
Registered: ‎03-08-2010

Re: ARB: Active vs Suspended STATUS on Decline?

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

Member
Posts: 5
Registered: ‎09-18-2014

Re: ARB: Active vs Suspended STATUS on Decline?

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.

 

 

Developer
Posts: 82
Registered: ‎03-28-2014

Re: ARB: Active vs Suspended STATUS on Decline?

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:

 

 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

Member
Posts: 1
Registered: ‎11-06-2015

Re: ARB: Active vs Suspended STATUS on Decline?

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.

Member
Posts: 10
Registered: ‎05-01-2012

Re: ARB: Active vs Suspended STATUS on Decline?

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?