I sent the following to support in the middle of last week, and have not yet seen a response. So I thought I'd try here. I have searched these forums directly and also done google searches, and I have not seen a solution to what we are trying to accomplish below.
We are using ARB to run a monthly subscription membership service. The first payment is performed through AIM since we want to start their website membership right away. We then start their subscription one month later. Each day we have a script that runs to determine whether memberships should be extended for another month or terminated. Up until now we have based this on whether their Authorize.net subscription status is "active" or not. If "active" we extend their membership; if the subscription is any other status, we stop their website membership.
When we first started doing this, it was our understanding that if a credit card was declined, the subscription would no longer have an "active" status. And in our testing this seemed to be the case, and in our early production usage this also seemed to be the case - declined credit cards on those first month's subscriptions did change to a non "active" status...
However, we have now discovered that it appears that only if the credit card is declined on the FIRST subscription payment attempt will the subscription status change to something other than "active." If the initial subscription payment is successful, though, and then later there is a decline it does NOT change the subscription status, and it remains "active." Which means we've had memberships go for months with "declines" on their credit cards while their memberships have remained in place.
This is NOT the behavior we want - if their card is declined, we want their membership on our site to cease. (We will restart a new subscription later if they want to start up a new monthly membership.) Thus, we need a way to determine if a subscription payment was declined.
I thought a good solution would be to somehow look up a list of transactions for a given subscription using one of the Authorize.net APIs, and then seeing if the most recent transaction was successful and basing the change in our website membership on that information - but it appears this is NOT an option in any of the APIs (i.e. there is no way to look up transactions based on subscription id... is this correct?).
Given that, our next thought was to turn on Automatic Retry. Are we correct that if that is turned on, it will set a subscription to "suspended" status on ANY decline? If so, my plan is to have my daily script check for "suspended" status for each subscription, and if "suspended" we will terminate their website membership and cancel the subscription on authorize.net
Does anyone see any problems with this idea? Is there a better approach? We thought about using the Transaction API, but since transaction settlement seems to happen haphazardly, sometimes a day or two after the transaction itself, this does not seem like a reliable solution for us (we would have to retroactively make checks, which seems cumbersome at best) - am I missing something here?
Also, another question: the Automatic Retry info indicates that once enabled, it cannot be disabled. Does this just mean that *I* cannot disable it? Or can the folks at Authorize.net also not disable it? In other words, if we enable it and something goes awry, can we message or otherwise contact Authorize.net to disable it for us? While it seems safe enough to turn on, we would really like *some* option to disable it if it somehow breaks something...
And one final question/inquiry related to all of the above: we would very much like to test all this out on the sandbox, including turning on Automatic Retry, etc. However, there does not appear to be any way to create "dummy data" in the sandbox. Because of this and because the sandbox works more or less EXACTLY like the production environment, it would be at least a week before we could test transactions on any "second" subscription payment transactions. And we can't test against real data without enabling Automatic Retry (which we are scared to do without testing! Catch 22...) Maybe there is a way to enter test data (subscriptions, transactions, etc) into the sandbox that I am missing? There really should be a way if there isn't - having to wait an entire week to test a feature of my application's interface with the system seems burdensome. It would be nice to be able to back date subscriptions, manually run transactions on them, allow some subscription transactions to be successful at first but decline later, and so on, in order to generate test data for different scenarios. While I see the benefit to the sandbox working like the production service, having the ability to manually manipulate test data would be really useful.
Thanks in advance for your time and wisdom on my issues above!
