topic Re: ARB: Active vs Suspended STATUS on Decline? in Integration and Testing

ARB: Active vs Suspended STATUS on Decline?

ayurvibes — Thu, 10 Feb 2011 21:42:58 GMT

I've read several posts here on the behavior of ARB when a scheduled payment is DECLINED.

From what I gather - for an EXISTING ARB subscription WHEN PAYMENT IS DECLINED:

1. If it is the FIRST scheduled payment or payment info has been updated recenlty, the subscription STATUS gets set to SUSPENDED.

Updating payment info sets subscription STATUS back to ACTIVE and the NEXT DAY at 2AM there is another attempt to process, no matter when the next subscription payment should run.

2. If there has been 1 or more past payments on the subscription, the subscription STATUS *STAYS* ACTIVE.

Updating payment info does nothing to STATUS and the next payment attempt is not run until the next scheduled date (could be 30 days away for a monthly subscription).

How does one programatically deal with these two scenerios which are BOTH DECLINES but ARB is not consistent with STATUS or NEXT CHARGE DATE?

Here's the workflow:

1. From SILENT POST we know an ARB payment has failed (DECLINED).

2. Next, check subscription status via API could be ACTIVE or SUSPENDED depending on 1 & 2 above! NO LOGIC HERE!

3. If SUSPENDED, update payment, ARB runs again *NEXT DAY* a 2AM. At the time of update you won't know if card is valid, so possibility of failure. Could do AIM AUTH_ONLY to prevent this, but that's an extra step. Can't do AIM catch up here because ARB would double charge the user, since SUSPENDED updates automatically run the NEXT DAY at 2AM!

4. If ACTIVE, update payment, ARB won't run again until next scheduled DATE. Have to process AIM Catch up payment to get account current.

Seems like the only accurate way to deal with a SILENT POST ARB decline is to cancel the subscription, do an AIM catch up and create new ARB subscription. Relying on API subscription STATUS is not accurate.

STATUS SHOULD BE *SUSPENDED* IN EVERY CASE when payment is declined! And also, the next payment charge date should be consistent and not vary if STATUS is SUSPENDED or ACTIVE!

It's way too much headache to try and programmatically account for all the scenerios above. You would have to store another DB field for LAST_PAYMENT_STATUS (declined, accepted) alongside ARB_STATUS (active, suspended, etc). This is a waste. What is ARB STATUS useful for if not to know if the subscription is active or not. And when a payment FAILS there is no good reason for a subscription to stay ACTIVE!

Please post the solutions that you've found for these issues.

Re: ARB: Active vs Suspended STATUS on Decline?

ayurvibes — Sun, 13 Feb 2011 20:16:59 GMT

bump...little help please?

Re: ARB: Active vs Suspended STATUS on Decline?

Michelle — Tue, 15 Feb 2011 00:03:29 GMT

Hey ayurvibes,

You've pretty much got all the details down. When ARB was first created, it was simply designed to create and execute recurring transactions so that developers/merchants wouldn't have to do that on their end. But there are some areas that could use improving and I have passed on your feedback to our development teams.

Thanks,

Michelle

Developer Community Manager

Re: ARB: Active vs Suspended STATUS on Decline?

ayurvibes — Thu, 17 Feb 2011 20:09:26 GMT

Michelle, thank you. Of course, I am very grateful for ARB and the work Anet has done to create this service. Everything is in a constant flux of growth and impovement.

I appreciate you sending the info on the to dev team.

I should have gone with the CIM and just wrote my own code to handle billing. Oh well, live and learn.

Do you guys have a way to import the ARB credit card info into CIM? If so I would switch. But I don't want to ask my customers to reinput payment info. You lose too many when you do that.

Cheers,

Jhaura

Re: ARB: Active vs Suspended STATUS on Decline?

Michelle — Tue, 22 Feb 2011 21:53:04 GMT

Hey Jhaura,

Currently no, but that is one of the top requested features we hear. The dev teams are already aware of the need, so fingers crossed!

Thanks,

Michelle

Developer Community Manager

Re: ARB: Active vs Suspended STATUS on Decline?

jbubbison — Thu, 23 Jun 2011 16:15:50 GMT

ayurvibes, your question is well-conceived and addresses many of the very same issues with which I am grappling. Thank you for taking the time to articulate the finer points and step-through the logic. I found your post quite helpful.

In your initial post you proposed the following workflow:

@ayurvibes wrote:
[...]

How does one programatically deal with these two scenerios which are BOTH DECLINES but ARB is not consistent with STATUS or NEXT CHARGE DATE?

Here's the workflow:

1. From SILENT POST we know an ARB payment has failed (DECLINED).

2. Next, check subscription status via API could be ACTIVE or SUSPENDED depending on 1 & 2 above! NO LOGIC HERE!

3. If SUSPENDED, update payment, ARB runs again *NEXT DAY* a 2AM. At the time of update you won't know if card is valid, so possibility of failure. Could do AIM AUTH_ONLY to prevent this, but that's an extra step. Can't do AIM catch up here because ARB would double charge the user, since SUSPENDED updates automatically run the NEXT DAY at 2AM!

4. If ACTIVE, update payment, ARB won't run again until next scheduled DATE. Have to process AIM Catch up payment to get account current.

[...]

The problem the proposed workflow is addressed in point 5, below.

All citations are from the ARB Manual, rev. 6/3/2011.

In general, the following issues with the ARB API require special attention from developers:

1.) Note on page 20: "If you create a new subscription with the first payment scheduled for that same day, the initial payment for the subscription will actually be submitted the next business day."

For this reason, and because a customer's payment information is not validated when a subscription is created (thus there is no reason to believe that the first scheduled payment will succeed), merchants should not grant customers access to subscription-required content without first charging the customer's card for some sensible amount. In the context of most applications, it is wise to charge the customer's card using the AIM or SIM API if the customer must have access to the merchant's subscription-required content immediately after submitting payment information for the first time.

2.) 3rd Note on page 21: "The Silent Post feature only returns responses for scheduled ARB transactions that are approved or declined. The payment gateway will not return a response to the specified Silent Post URL if the scheduled transaction results in a general error due to expired or invalid payment information." The manual reiterates, on page 22, "ARB subscriptions only generate Silent Post responses if and when a transaction processes. If a transaction does not process, for example, if the credit card has expired, a Silent Post does not occur (see General Errors for Individual Payments in a Subscription on page 27 for more information). It is recommended that you configure the ARB specific email notifications within your account as well as using Silent Post for the purposes of identifying ARB subscription activity."

Silent Posts and email messages, alone, do not allow for developers to build rock-solid applications, so Authorize.Net's recommendation is unreasonable. Neither method is 100% reliable given that Silent Posts and email messages cannot be resent at any time. Even though, according to the 1st paragraph of page 30, the Merchant Interface on authorize.net does provide the details of individual ARB payments that fail due to invalid billing or expired payment information (on the Completed Transactions page of the merchant interface), developers do not have programmatic access to this information (and have no access at all under developer accounts).

3.) 1st Note on page 21: "The Daily Transaction Summary email returns an Excel file in comma separated value (.csv) format. The merchant will receive Successful.csv, Failed.csv or both files."

If this email's delivery were guaranteed (which is not realistic), the manual does state, in the Note on page 30, that "Payments with general errors can be identified on the completed transactions page of the Merchant Interface. They will display 'N/A' in the Transaction ID field and 'General Error' in the Transaction Status field."

I have not inspected "Failed.csv" yet, but assume (based on the above passage) that it lacks detail as to WHY each General Error occured, thus making it fairly useless for most purposes.

4.) 2nd Note on page 21: "Test environment accounts do not process ARB subscription transactions. If you are using a test environment account, you will not receive these email notifications [referring to ARB emails described at the bottom of page 20] in any form. You will also not be able to receive an ARB subscription transaction Silent Post while using a test environment account."

These facts make testing application logic that relies on emails or Silent Posts incredibly difficult.

5.) 3rd paragraph of page 22: "Silent Post responses are returned in real-time, meaning as soon as the transaction processes we send out the Silent Post to your specified URL. We do not necessarily update the subscription in real-time, however. This means that you should not use the Silent Post response to immediately update or cancel an ARB subscription. If you update or cancel a subscription before we have updated the subscription in our system, our update will overwrite any changes you may have made. You should instead simply collect the response data and submit any changes necessary in your subscription(s) later that day."

The logic behind this API behavior is puzzling (why aren't the subscription statuses updated FIRST, then the emails sent?), and it could render the original poster's proposed workflow problematic.

This API behavior forces developers to batch-process subscription information at a specific time of day that does not conflict with the 2AM PST time at which Authorize.net updates its subscription statuses. This is less than ideal, especially given that a developer has no means by which to know how long after 2AM PST all merchant subscriptions will have been updated on Authorize.net's server.

The disparity between the time at which a Silent Post is sent for failed individual subscription payments and the time at which the subscription status changes occur on Authorize.Net's servers renders Silent Post information useful only for batch-processing (and not for updating subscription statuses in real-time).

6.) Subscription Suspension bullet-point on page 20: "A subscription will be suspended if the first payment in the subscription is declined, rejected or receives an error response." In the middle of page 29, the manual states further, "Anytime an error occurs that prevents the payment gateway from processing a scheduled payment in a subscription, the payment will result in a general error. For example, if the credit card expiration date on file for a subscription is not updated before it expires, the next scheduled payment will not be processed and the transaction will result in a general error. These subscriptions will not be suspended or be automatically terminated unless the general error occurs on the first scheduled payment in the subscription."

Subscriptions for which the first scheduled payment succeeds will never go into "suspended" status if any payment after the first fails to be processed for any reason. This behavior seems absurd (as the original-poster noted). How are developers or merchants expected to address failed OR declined payments for subscriptions without resorting to manual processes?

Any API that requires manual processes to be performed does not scale and should not be considered for use in any serious application.

I have additional conerns relative to the ARB API, but these are the most fundamental.

Re: ARB: Active vs Suspended STATUS on Decline?

TechStu — Fri, 24 Jun 2011 20:28:21 GMT

The original post says "Updating payment info sets subscription STATUS back to ACTIVE and the NEXT DAY at 2AM there is another attempt to process, no matter when the next subscription payment should run."

I could not find this anywhere in the current documentation. Is this something that no longer happens or am I just not seeing it in the documentation?

Re: ARB: Active vs Suspended STATUS on Decline?

TechStu — Mon, 08 Aug 2011 13:57:36 GMT

@TechStu wrote:
The original post says "Updating payment info sets subscription STATUS back to ACTIVE and the NEXT DAY at 2AM there is another attempt to process, no matter when the next subscription payment should run."

I could not find this anywhere in the current documentation. Is this something that no longer happens or am I just not seeing it in the documentation?

I've found that this is the case in the test environment. Can someone please verify how the live environment works? I've seen posts that state both ways and it's pretty important to know if it will or will not try again the next day. Thanks.

Re: ARB: Active vs Suspended STATUS on Decline?

TJPride — Mon, 08 Aug 2011 23:27:07 GMT

I'm rather wishing I'd gone with CIM as well. It seems a lot more straightforward, and avoids having to use two billing methods (AIM + ARB) rather than one (CIM).

Re: ARB: Active vs Suspended STATUS on Decline?

Michelle — Wed, 10 Aug 2011 19:35:50 GMT

Hey there,

The same behavior in the test environment occurs in the live environment. If a subscription suspends on the first payment, the subscription hasn't technically started yet. So the subscription will actually try to start again after you update the subscription info. That means that the first payment will be attempted again the next day.

Thanks,

Michelle

Developer Community Manager

Re: ARB: Active vs Suspended STATUS on Decline?

TJPride — Wed, 10 Aug 2011 19:42:54 GMT

Would be more helpful if it worked that way as well for subscriptions that have processed one or more payments. Any chance of adding a control panel setting that allows you to choose behavior?

-Ted

Re: ARB: Active vs Suspended STATUS on Decline?

Michelle — Thu, 11 Aug 2011 20:13:10 GMT

Hey Ted,

I can certainly pass that suggestion on to our development teams. Can't give you any kinda quote on when or if that will be implemented, but I can tell you that they take feedback from the community very seriously.

Thanks,

Michelle

Developer Community Manager

Re: ARB: Active vs Suspended STATUS on Decline?

TechStu — Mon, 15 Aug 2011 16:30:34 GMT

Is there times when the first payment can be declined and NOT go into suspended mode? It seems that just happened in my developement environment but I thought if the first payment was declined the arb would always be suspended. Please clarify, thanks.

*Edit: I am pretty sure that I did update the ARB with a new payment amount prior to the first payment. Would that cause it not to go into suspended mode?

Re: ARB: Active vs Suspended STATUS on Decline?

Joy — Fri, 19 Aug 2011 17:02:53 GMT

Hi TechStu,

It doesn't happen in normal circumstances, if the first payment was decline then the subscription will go into suspended status, if you got a decline instead I suggest that you email developer@authorize.net if you have specific examples you would like more information on or you can also contact our Customer Service.

Thanks!

-Joy

Re: ARB: Active vs Suspended STATUS on Decline?

supercleanse — Wed, 22 May 2013 14:23:31 GMT

This was posted 2 years agon now ... is this still the way ARB handles declines?

Is the AIM "catch-up" still necessary after the user's cc info is updated?

It would be very helpful if ARB is able to rebill within 24 hours after the user's credit card information is updated ...

Thanks,

Blair

Re: ARB: Active vs Suspended STATUS on Decline?

ptlapa — Fri, 16 May 2014 14:16:26 GMT

This issue of ARB not able to handle declined credit cards until the next billing cycle is an absolute joke.

Are you kidding me? Should we just give away a free month because you can't support your customers requirments?

And no, manually adding the corrected payment via your virtual terminal is no solution. The history of the ARB is broken (as it takes too much effort to figure out what the result of the decline was on the account).

With all the millions of Target customers issued new credit cards this year, this liability is just too big. I am starting to seek out a 'better' solution.

This issue was raised way back in 2011....Shame on you for not listening to your customers.

Re: ARB: Active vs Suspended STATUS on Decline?

RichardH — Fri, 16 May 2014 15:30:02 GMT

Hello @ptlapa

We appreciate you raising this enhancement request again. However, I can tell you that the product team is actively discussing this and other request to improve our recurring billing features through the API.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Re: ARB: Active vs Suspended STATUS on Decline?

alippert — Fri, 19 Sep 2014 02:26:34 GMT

Another 4 months on - updated status? We are about to tackle this problem and it would be REALLY helpful to have it funcitoning in a fashion that SUPPORTED development.

Re: ARB: Active vs Suspended STATUS on Decline?

healthsuccess — Sat, 31 Jan 2015 13:38:15 GMT

Following

Re: ARB: Active vs Suspended STATUS on Decline?

alippert — Tue, 24 Mar 2015 21:23:29 GMT

Another year - and this issue STILL lingers. To the Auth.net team - I am quite certain you have no concenption of exactly how onnerous this particular design choice makes things for your customers. Consistency of behavior - all declines mark subscription status as SUSPENDED. Any subsequent update to payment method tries the catch-up transaction - wuold make ALL of our lives very much easier. The current situation is literally indefensible. How about taking a few minutes and fixing this obvious design flaw.

Thanks