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,
Elaine
