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.

[brianmc]

Hi guys,

The major overhaul in our ARB & CIM architecture is almost complete.  In the next few weeks we'll be releasing updates to our API to allow ARB subscriptions to be created from CIM profiles.  This will not solve all the ARB issues in this thread (yet) but it does mean that CIM card validation will be available when you want to create/update a subscription rather than waiting for validation on first charge.  Please be assured that tackling the ARB fail/retry is next up on our agenda but getting the underlying design correct had to be our first task.   We hope that this major update (and data migration) demonstrates our commitment to our card-on-file services.   Obviously this thread is a comprehensive document on the retry issues but if you would like to provide direct feedback to me on your particular recurring billing use case please feel free to email me directly at bmcmanus(replacewithatsign)authorize.net.

thank-you,

Brian 

[bpautsch]

No updates in 5 months? So I emailed Brian Mcmanus directly as he suggested...no reply. I will now be moving all of my customers to PayFlow Pro. I coded their API 2 years ago and they support everything everyone is looking for in a real ARB system.

[brianmc]

Apologies for not responding sooner Brian, we have been extremely busy as I'm sure you are too so no excuse on the email response delay.

Re ARB as I mentioned in email we have a major project in the plans for ARB upgrade and we have had to balance the cost/impact/maintenence of any interim updates.

That being said we can look at the possibility of providing API access to the existing MINT retry functionality.

Thanks for the feedback and apologies again for the radio silence.

Brian

[budershank]

Well reading this thread was a bummer.  I was thrilled that I could use the ARB system which would save in both developer cost and maintenance but not having a good way to handle declined payments basically makes it a no go. 

What a shame :/

[rev23dev]

Dealing with this again as I'm completely rebuilding my website from the ground up.  Such a ridiculous headache.

[brianmc]

I hate having to apologize for the delay again but we are finally moving with ARB updates and we will be making some great (and long overdue) improvements to our recurring billing in the next few months.  If you can hold out and/or you are interested in taking part in a beta please email developer@authorize.net with the subject of ARB Beta and ask to participate.

Brian 

[rev23dev]

Thanks for the reply, Brian.

Super interested. Can you detail the improvements a little bit though so we can better determine if we want to beta? :)

[kos]

Hi Brian,

Any updates on this? May you give more detailed ETA when this issue is going to be solved?

[Aaron]

Hi @kos,

I may not have a detailed answer for you right off the bat, but I can certainly look. Let me first ask what specific changes you're looking for.

This thread goes back a ways, and some of the things that have been discussed have been changed and others haven't. If you tell me what specific recurring transaction problem(s) you're dealing with, I can investigate and see where in the planning we are for that particular improvement. 

[kos]

Hi @Aaron,

Nice to hear from you.

The problem is that declined transactions don't change subscriptions' status to "Suspended" if transaction wasn't initial, but second or later.

In this case we must create missed payments manually and there is no way to connect these payments to subscription (there is no way to manually set subscription_id to transactions). We are tracking all transactions for user's subscriptions. This way we are able to show Payment History of particular customer, but these manually created transactions won't be involved. And all these problems could be solved, if subscription got "Suspended" status on any failed transaction.