ARB Use Case Questions

[rbn-jamie]

Hello!

I've spent the afternoon writing some Python bindings around the ARB and AMI XML APIs (enough initialisms?).  Everything seems to be working well and I'll likely roll it into production within the next week or so.  However, after reading the docs and some of the forum posts, I did have some questions about the functionality:

1. ARB does not charge the customer when the subscription is first created.  So my plan is to run the first charge through AMI and then create a ARB subscription. If I want the customer to be charged again a month later, do I set "startDate" in my subscription to today's date or one month in the future?

2. The docs are a bit confusing. They read:

"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."

In my use case, a customer signs up for a 12 month subscription with monthly billing.  If, six months later, the customer cancels that credit card and the subsequent charge fails, how do I detect that?  Won't issuing a "ARBGetSubscriptionStatusRequest" on the subscription tell me that the previous charge attempt failed?  If so, what is the returned status code?

Thanks!

[TJPride]

1. Set it for a month from now.

2. You should configure a Silent Post page, which receives transaction data every time a charge attempt goes through. If the charge fails, you can detect the error there and perform some action to notify yourself and/or the customer that the card needs to be updated. Fields passed should include subscription ID, customer ID (if you set that), customer email (same), and of course an applicable error code (8 and 317 are for expired credit cards, for instance). You should also get notices of failed transactions from Authorize.net.

If you want to get familiar with Silent Post, the best way is to have it log the output of print_r($_POST, true) to a file, then send AIM transactions through. The fields received will be exactly the same, outside of just a few like subscription ID and of course the error codes. Keep logging even when you switch over to actual live ARB subscriptions, that way if you miss an error code, it's not the end of the world - Authorize.net will send you an email and then you can check the log and add that error code to your Silent Post page for next time.

The ARB guide is not terribly forthcoming when it comes to what statuses you can get back out of ARBGetSubscriptionStatusRequest, my advice would be to call it for an active subscription and a canceled subscription and see what you get. You can probably reverse-engineer from there. I just use Silent Post myself to keep things accurate.