Authorize.Net’s Automated Recurring Billing (ARB) allows you to run subscriptions from within Authorize.Net. Once you create a subscription, it will have a status value. The status value for a subscription can be one of the following:
Unfortunately, I found these statuses and when they occur a bit confusing so I wanted to record my findings (so after I’ve forgotten, I don’t have to figure this out all over again).
When a subscription is first created it has a status of
active. As long as each recurring transaction happens successfully, the status will remain
If you are using webhooks, the
net.authorize.customer.subscription.created webhook is fired when the subscription is created.
Note: Even if the payment profile associated with the subscription (e.g. a credit card), is going to be declined the subscription starts as
active. Since subscription payments are batched processed each day around 2:00 a.m. PST source, a subscription with a bad payment profile can remain active for many hours before it is discovered the payment profile is going to be declined and the status can change.
If the first payment is declined, rejected, or receives an error response, the status is changed to
suspended source. The webhook
net.authorize.customer.subscription.suspended is fired at this time.
If you update your subscription (payment information or shipping information), the next payment is treated as a “first” payment. If this payment is declined, rejected, or receives an error response, the status is changed to
If any non-“first” payment is declined (for example your second payment), the status of the subscription does not change. In other words, even though subscription payments may fail repeatedly, as long as they aren’t a “first” payment the subscription stays
This can lead to
active subscriptions without any payment as evidenced in this Community Forum Post: subscription transaction declined but subscription still active.
Which means we’ve had memberships go for months with “declines” on their credit cards while their memberships have remained in place.
This includes if a card expires after the first payment, the status remains
Avoid Declined Transactions Remaining Active
Authorize.Net has introduced the ability to avoid the problem of subscriptions remaining active when a transaction fails with Automatic Retry. While this feature is poorly name and difficult to understand, it is worth learning about.
When Automatic Retry is enabled, when a non-“first” payment fails instead of leaving the status as
active, the status is changed to
suspended. The charge will not be attempted again until you update the subscription’s payment information. Once the subscription payment information is updated, Authorize.Net will automatically retry the payment. The subscription status will remain
suspended until a payment is made successfully. A subscription can remain
suspended indefinitely when Automatic Retry is enabled.
Note: Automatic Retry can not be disabled once it is enabled.
I suspect, and this is purely conjecture on my part, Authorize.Net has come to see Automatic Retry as the proper default behavior but in order to not introduce a breaking change to their API they’ve added as an option you can enable.
The schedule of payments has ended.
I’ve found in my work, the ARB subscriptions I’ve been setting up have been exclusively without a fixed number of payments (i.e. they could go on forever), therefore this status does not come up in my work.
The subscription was cancelled using ARBCancelSubscriptionRequest. A cancelled subscription no longer exists and cannot be reactivated.
In other words, either through the web interface or an API call the subscription was cancelled.
When a merchant takes no action on a suspended account before the next runDate, the subscription is terminated. Once terminated, a subscription can no longer be reactivated and must be recreated.
If Automatic Retry is enabled, no subscription will be assigned a status of terminated.