Showing results for 
Search instead for 
Did you mean: 

ARB Auto Retry flow

I've enabled Auto Retry on ARB, but it still could use some work.


I have SaaS software that is susbscription based. When the transaction declines, software gets shut down. Simple enough.


Previously, I would charge their card for the declined payment and ARB would just bill again the following month.


Now with Auto Retry, it obviously bills the next day once updated. The problem is I can't just assume that by them updating the subscription will approve the next day and turn them back on, only for it to get declined again.


Obviously I have to do some kind of auth on the card. I auth the card for the amount due, but the problem is when it reruns the next day, that auth is still hanging out there so people see two transactions and think they've been double charged which leads to support time for me explaining they've not been double charged.


What's the best flow here?


What seems ideal is if we could do an auth, update the subscription and have it capture that authed transaction the following day?


But, how can one handle this now? Just void the transaction right after the auth? How long will that stay on their statement for before dropping off?


Hit my first one of these this week. ARB suspended it, customer came to my site to reactivate, authorized their card and it was good, then when ARB ran again this morning it declined again. This is a vicious cycle. What are we supposed to do here? Please help.




Apologies for your inconvenience.


Unfortunately, I do not completely understand the flow that you are trying to achieve.


From what I understand,


  • Your subscriptions are getting declined. Any reason why? An error response code will be returned in this case.


  • You are expecting some update when the transactions are declined. What are you updating? And in the event that you are updating the credit card number, any reason why you are doing an AuthOnly transaction with it?


  • If you feel that the AuthOnly transaction is compulsory, then is it not possible to Void it after you are satisfied with the response? This will allow the ARB transactions for the next day to work without the duplicate authorization.



My subscriptions get suspended for a variety of reasons. Mostly declines because they don't have money in their account.


The problem is if I authorize then void, then wait for the next business day, it's possible these guys don't have money in their account again which will decline and suspend the subscription again.

Hi rev23dev


I certainly understand the frustration you are feeling in this scenario. This, unfortunately, can be a difficult hurdle to overcome as ARB does not process transactions in real-time and the customer can sign up with their card, you can validate the card at subscription creation and then, when it comes time to run the subscription payment, the customer doesn't have enough funds to cover the recurring subscription amount. It's not an uncommon problem that many merchants face when it comes to recurring subscription payments.


How to handle this for your business' needs is likely dependent upon how your SaaS uses the subscription status, or rather if you use this status to identify whether to allow access or not. 


If you rely on the ARB subscription status (Active, Suspended, Cancelled) then, unfortunately, you will be at the mercy of the customer's balance availability at the time that the subscription transaction processes. 


I would not really recommend that you run an authOnly transaction for the amount first, for the reason that you mention; the customer may not have enough to cover the authorization of this amount twice even though one is only an authorization and will never settle (if you don't void it, it will naturally return back to the customer's available balance based on the issuer's schedule for doing so). 


If you do not rely on the subscription status, I might recommend the following flow. 


  • Update the CIM profile created by the ARB subscription using an  updateCustomerPaymentProfileRequest
    • This is what is used by the ARB subscription to charge the customer when it runs during its regular interval
    • This update WILL NOT un-suspend the ARB subscription
  • Submit a createTransactionRequest using the CIM profile created for the subscription that you have just updated with the updateCustomerPaymentProfileRequest with an authCapture transaction type for the amount of the failed payment
  • If successfully authorized, allow the transaction to settle normally
  • If declined, notify your customer to provide another form of payment
  • Once this process has completed and the customer has delivered on their commitment of payment, DO NOT un-suspend the ARB subscription
    • Instead, on the date of the next subscription interval run (i.e. the subscription bills on the 7th of every month, un-suspend the subscription on the 7th) 
    • This will prevent Auto Retry from "re-trying" the failed payment as you will have passed by the last interval entirely and ARB will simply move on as if no payment should have occurred on the previous interval 
    • This only applies after the first successful transaction has processed within a subscription as the first payment of an ARB subscription is not applicable to Auto Retry by design

I certainly understand that the above flow is not ideal however, based on how ARB runs at a specific time each day, and not in real-time, if you are searching for a real-time auth and response to ensure that your customer's payment data is valid for the amount in question, the above would be my recommendation. 


I hope this is helpful to you. 


Thank you,


Another annoying trait has about this has been popping up recently.


Let's say an ARB is set to bill on the 15th of each month. Imagine it fails to bill on September 15th. On October 13th the card holder finally decides to update their subscription. On October 14th they will be billed from the subscription reactivating, then will get billed again on October 15th.


With no ability to update the next payment date, this is a bad flow for everyone involved, the card holder and customer support.

What's with all the spam in these foums lately? Does anyone from Authnet actually monitor these at this point?


I need to just bite the bullet and move to something with more modern tech (.net standard/core support) and better support. This has gotten to be ridiculous.