01-25-2016 09:18 AM
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.
06-21-2016 08:57 AM
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.
06-21-2016 09:25 AM
11-04-2016 04:59 AM
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 :/
01-13-2017 07:54 AM
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 firstname.lastname@example.org with the subject of ARB Beta and ask to participate.
03-17-2017 08:38 AM
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.
03-30-2017 03:50 AM
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.