and ARB Race Conditions

So I've had a problem on a recent project ever since I started using's recurring billing system. While it works fantastically for the most part, I've had issues with canceling subscriptions during their nightly billing process. The issue at hand is that doesn't actually cancel a subscription if a transaction is declined. They leave the subscription active and will just continue to try again and again until the subscription actually ends. The above scenario doesn't really work for a subscription based website. Perhaps it does for a magazine, but if a user's payment on a site fails, the subscription should be immediately cancelled, the user should be notified, and then they can attempt to renew the subscription at their convenience. That's all well and good, no problem. When I receive the nightly post from with all of the success and failures, I just turn right back around and submit a cancellation request for each transaction that was declined. The request to cancel the subscription looks like this: #variables.loginname# #variables.transactionKey# #Arguments.subscriptionId# And the response back from looks like this: Ok I00001 Successful. That's awesome right!? I sent a request, they responded that it was successful, all is peaches and cream. **WRONG**. Apparently, my cancellation request gets to's ARB api before their own system adds the transaction to the subscription and updates the next billing date. This results in me getting a successful response back from, and then overwriting my cancellation with the results from their own transactions. So the flow is going something like this: * sends post to my processing script * Read the results, and if the transaction is declined: * Update my user record * Update my subscription record * Email the user that there was a problem * Send an HTTP request to ANet to cancel the subscription * I receive a success from * finishes their processing and then updates the same subscription with an Active status and a new billing date, wiping out my cancellation verified that this was exactly what's happening and told me that I need to queue up my cancellations that happen during the nightly billing, and run them no sooner than one hour after I receive their posts. Shouldn't my api updates take precedence over's? According to the ANet API it shouldn't even be possible to "un-cancel" a subscription. Once it's canceled, you have to create a new subscription. Anyway, the main point of this post was to let other's using the ARB API to be careful about your updates during ARB's nightly posts. I've created a queue table for this purpose, and just drop all cancellations into the table and run them on a schedule so that they're all posted 2 hours after they're received (figured I should give ANet plenty of time).
Posted by Daniel Short on Mar 18, 2009 at 8:51 AM | Categories: ColdFusion - Rambling -


Joe Zack

Joe Zack wrote on 03/26/09 11:28 AM

I've had some strange issues with SkipJack's Recurring Billing API as well, I'll have to check if something similar is going on!
Daniel Short

Daniel Short wrote on 03/26/09 2:35 PM

Hope it points you in the right direction.

Robin wrote on 09/26/12 1:47 PM

Thank you for your post. I'm sure I'm going to have to address these issues once I get the basic create subscription working. I'm unclear the best, simplest approach to setup recurring Authorizenet subscriptions with ColdFusion. I googled and found your post. Do you have an example of how this was setup using ColdFusion? I'm also unclear on how to parse the returned values. Thank You.