topic Re: subcription transaction declined but subscription still active in Integration and Testing

subcription transaction declined but subscription still active

SodaBob — Mon, 08 Jan 2018 17:07:18 GMT

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!

Re: subcription transaction declined but subscription still active

rajvpate — Mon, 08 Jan 2018 18:12:46 GMT

Hi,

Yes you are correct to observe that *without Auto Retry* the subscriptions would get suspended due o AVS failure only if its the FIRST run OR if the subscription was updated.

Enabling Auto Retry is one option to have the subscriptions fail everytime there is a failure related to credit card data.

I hear your concen, but I am not sure if it's possible even by CSR to revert back to No-Auto Retry, but let me check with the team and get back to you.

Re: subcription transaction declined but subscription still active

SodaBob — Mon, 08 Jan 2018 20:02:57 GMT

Thank you for the confirmation on Auto Retry, and I thankfully await your response regarding the ability to revert to no-auto-retry.

Re: subcription transaction declined but subscription still active

rajvpate — Mon, 08 Jan 2018 21:12:02 GMT

Hi,

It is not feasible to update values for reverting Auto-Retry in sandbox environment. As you mentioned, a 7 day subscription under test in cert test would be the shortest window to test the behaviour.

Regards,

~ Rajvi

Re: subcription transaction declined but subscription still active

SodaBob — Mon, 08 Jan 2018 21:24:20 GMT

Just to make sure I'm understanding, if we turn on Auto-Retry in the sandbox it cannot be reverted, but what about the production authorize.net service?

In the test sandbox environment, is there a way to have the first transaction for a subscription be successful, but the second be declined?

Thanks...

Re: subcription transaction declined but subscription still active

rajvpate — Mon, 08 Jan 2018 22:24:49 GMT

Hi,

It is not possible to revert back from Auto-Retry in sandbox or in production environment.

In the sandbox environment, if you have turned on Auto-Retry, and a subscription has been created using a non-error amount as per the Testing Guide here: https://developer.authorize.net/hello_world/testing_guide/

for example with amount = 5.00, it should be successful for the first run.

Then, after the first successful run, if the subscription is updated from MINT UI with the billing zipcode = 46282 (As per section Generating Card Responses->GENERAL RESPONSES), the transaction should be declined. This should then mark the subscription as SUSPENDED.

I have submitted a test transaction for a merchant enabled for AutoRetry in Cert env with amount 5.00 (just as suggested) and can let you know the results once ARBTGen is run at 08:30 GMT/12:30 AM PST.

Hope this helps.

Thank you,

~ Rajvi

Re: subcription transaction declined but subscription still active

SodaBob — Tue, 09 Jan 2018 13:23:28 GMT

That is great information, thanks so much! I look forward to the results of your final test.

Re: subcription transaction declined but subscription still active

rajvpate — Tue, 09 Jan 2018 17:52:55 GMT

Hi,

As expected, the subscription in CERT env with the Merchant that had AutoRetry enabled, passed successfully.

I have now updated the Billing zipcode to 46282 as per the testing guide and expect it to fail on the next run. Will let you know once I see results.

Is there anything else you need ?

Re: subcription transaction declined but subscription still active

SodaBob — Tue, 09 Jan 2018 21:01:45 GMT

No, that is it! Thanks so much!

I have set up some test subscriptions of my own in my sandbox using your suggested method above. I will use them to test over the next week.

I will set your first response as the solution, though all of your posts had great info.

Re: subcription transaction declined but subscription still active

mveerabh — Tue, 09 Jan 2018 22:51:02 GMT

Hi,

There is way to know whether a subscription transaction is declined or not irrespective of first or any another occurence. you can call GetSubscription Api to get latest 20 transactions for given subscriptionId and then call GetTransaction Details Api using latest subscription transaction Id to know whether subscription transaction is declined or approved. To get latest 20 transactions, use includeTransactions flag in GetSubscription api call as below:

Thanks

Re: subcription transaction declined but subscription still active

rajvpate — Wed, 17 Jan 2018 21:58:21 GMT

Hi,

Just getting back with more information on the test subscription that I had set up in CERT env with amount 5.

As expected the second transaction for the subscription was suspended and here is a screenshot with some details.

So, it is possible to have the second transaction suspended in CERT env for your testing.

Re: subcription transaction declined but subscription still active

blackwood821 — Fri, 03 May 2019 13:25:22 GMT

@SodaBob I'm quite late to this thread but I'd like to know how Auto Retry worked out for you? Did you encounter any issues once you enabled it? Do you see any reason not to enable it? I have a similar monthly membership setup and I would also like to have the subscription suspended on any payment decline whether it's the first transaction on the subscription or not.

Also, I'm curious to know if you're using the

net.authorize.customer.subscription.suspended

webhook event so that you don't have to setup a cronjob.

I created a somewhat similar thread a while ago and have yet to get a response from Authorize.Net in the last 15 months. So I searched more through this forum and came across your post which looks promising.

Looking forward to your response. Thanks.