Integration and Testing

[avekm]

Hello,

I was wondering if I could get some guidance regarding best practices for recurring billing.  Let's say you have a monthly

subscription site.  You add the ARB subscription to auth.net and everything is good there.  How internally on your site do you

check that this user is a subscribed user on a go forward basis?  Do you check ARB subscription every time the person 

signs in?  Do you store a flag in your user record that tells you when this subscription expires?

I know that there are many variables that go into this and it is all site specific but  I'm looking for a discussion of how

you have handled subscription management on your website.  I'm new at this so some guidance, best practices, white

papers, anything on how to logistically handle recurring billing would be a huge help.  Thank you.

[SublymeRick]

I've never used auth.net's abr but I have use'd a similar technology from a different provider so I'm assuming the processes is similar, but either way take this with a grain of salt...

On the system I used, there was a "postback" script I was able to assign, such as "postback.php" on my server. The system would then send post data to that script with results from "auto-renewal" transactions. Either a success or a fail. So the best way I found to handle what you are asking was that as long as the account is marked in good standing in your dabase your code should assume the the subscripiton is valid. Only when the postback script gets a report saying an auth failed on a renew for X account, your script shoul dmark that account as "delinquent" or whatever status you want to give it in your system. The postback script could also be programmed to send an email to the subscriber letting them know the autorenew failed and to log in to update their payment info. I also had to modify my log-in script to redirect delinquent accounts to a page where they coul dupdate their payment info.

I'm not sure if auth.net does that postback thing. But i'd imagine they do, and if they do, this is the best way in IMHO.

[avekm]

Thanks Rick.  That is exactly the type of information I was looking for.  

Does anyone else have any experience(s) to share? Maybe someone who is currently using ARB? Another thing that would be good to know is what type of information of the

subscription are you saving in your user database to reconcile the user to the subscription?  I would think probably the subscription ID? Anything else?

[SublymeRick]

Again, no auth.net abr but the EPN gateway I was using would assign a "recur id". I attached this to the invoice my post back script created for reference. Everyt time a postback was received from a recur execution, my post back script would create an "invoice" for either a successful renew or a failed renew, either or. On that system when the recur failed the recur setup was autmatically cancelled so when the user updated their info a new recur would have to be set up, and that new assigned recur id would be attched to the invoice generated at the time of renewal.

The invoices were obviously attached to subscriber accounts. Things I would keep in the inovice records would be a unique invoice id, txresult, recurid, subscriber id, date / time and amount.

The administrator panel was able to view / print / email invoices as well, I had the system always email the customer with a copy of the invoice when generated.

It was a pretty advanced system I wrote for this, took a lot of time and figuring out how to handle all  this stuff, much like what you're dealing with right now so I feel your pain.

[jbubbison]

avekm,

You may wish to have a read through my recent post at http://community.developer.authorize.net/t5/Integration-and-Testing/ARB-Active-vs-Suspended-STATUS-o... .

In short, I have several serious concerns regarding the ARB API and they are summarized quite nicely in the above-referenced thread. The thread-starter underscores several legitimate concerns, too.

In my limited experience, the only means by which to build an application that relies on the ARB API is NOT to rely on the Silent Post feature or any automated email that Authorize.net may send (for the reasons outlined in the other thread).

The alternative is to call the ARBGetSubscriptionStatusRequest method every time a customer logs-in. If the customer's subscription status on the Authorize.Net server does not match the subscription status in your local database, the remote value should overwrite the local value.

Then, if the customer's local subscription status is:

ACTIVE: No action required; customer's subscription is current. (See IMPORTANT NOTE 1, below.)

EXPIRED: Customer is denied access to subscription-required content and required to create a new subscription.

SUSPENDED: Customer is denied access to subscription-required content and required to update existing subscription.

CANCELED: Customer is denied access to subscription-required content, but only if he hasn't pre-paid for access that extends beyond the current date. (See IMPORTANT NOTE 2, below.)

TERMINATED: Customer is denied access to subscription-required content and required to create a new subscription.

IMPORTANT NOTE 1: The problem with this approach is that it is possible for a subscription's status on the Authorize.Net server to be "active" even when the customer has not been charged successfully for any number of past payments. The reason for this is that subscriptions are placed into "suspended" status ONLY when the FIRST scheduled payment fails to be processed. In other words, as long as the first scheduled payment is processed successfully, the subscription's status will NEVER change to "suspended" when any number of payments fail or are declined.

IMPORTANT NOTE 2: The problem with this approach is that without relying on Silent Post or automated email messages, it is not possible to know at WHAT TIME the customer's subscription status changed (unless a cancelation was triggered on the local server and the request timestamp logged; cancelations performed through the Merchant Interface would have no such timestamp associated with them). Until Authorize.Net includes status change details in the ARBGetSubscriptionStatusRequest response, canceling subscriptions from the local application side is the only reliable approach to governing customer access to subscription-required content where cancelations are concerned.

Ultimately, I've come to the same conclusion as ayurvibes: ARB may not be a viable solution. Perhaps the CIM (Customer Information Management) API, with all subscription logic handled via the local application (most likely executing scripts on a schedule), is the way to go.

[avekm]

Thank you for the great info jbubb.  I had thought about bypassing the silent post however, how would you communicate a charge to your customer?  Let's say I want to provide my subscriber with a  list of payment transactions.  Would I gather that history from a silent post and save it in a transaction history table on my end?  What happens if your site is down when the silent post happens?

I read through the thread that you posted and auth net seems to acknowledge the problem but this seems like a deal breaker to me?  Sounds like here is no real way to recover from a missed payment. I was excited to get started with ARB but it seems to be half baked.  

I will try to see if I can contact ayurvibes and see if he has come up with a work around.  In the meantime if anyone else has some ideas on how to workflow ARB with subscription sites...please share.