12-31-2018 07:41 AM
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?
01-18-2019 12:22 PM
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.
01-24-2019 09:59 PM
Apologies for your inconvenience.
Unfortunately, I do not completely understand the flow that you are trying to achieve.
From what I understand,
03-26-2019 12:34 PM
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.
03-27-2019 04:08 PM
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.
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.
10-19-2020 09:05 AM
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.
11-17-2020 08:30 AM
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.