Suggestions/best practices for implementing a CIM-based recurring billing scheduler

[ksanchezssmci1]

Hello, 

I am looking for suggestions/best practices for implenting a CIM-based recurring billing scheduler using the Authorize.Net C# SDK  and CIM and Transaction API.  I searched though the forums, but only found answers stating that I would need to create my own scheduler,  but not any that provided guidelines or info on any caveats that might arise whe doing so.

My approach for implementing a scheduler is as follows:

1. Create a console application which I can set as a task to run every night on the server that hosts the database that stores the CIM Customer Paymet Profile Id's.

2. After I get a list of customer payment profiles id's, I loop through them and use the createTransactionRequest method to authorize and capture a set amount for each customer profile.

3. For my own records, I save transaction info for every successful transaction.

My concern arises from the fact that the above seems too simple.  I will have error handling and logging in there, but I am worried I am missing something.

Questions:

1. Is there a point at which there are so many customers that need to be charged in one night that it might be best to use a different approach, perhaps one that does transactions in batches?

2. Does Authorize.Net provide any service that allows batched, CIM-based transactions?

3. Also, from what I can tell,  the C# SDK methods are not asynchronous.  I have been dipping my toes into asynchronous programming, and I can't help but think that it would be advantageous if transaction methods in the SDK where async.  Are there any plans for this in the future?

Based on my simple approach above, does anyone have any suggestions/guidelines that they care to share for implementing a successful CIM-based scheduler?

-Thanks 

P.S. I looked into ARB but decided that CIM allows for more control.

[EddieLascu88CNP]

I have a somewhat similar situation where I need to process payments continously for my client's customers. The customers have the option of signing up for pre-authorized top-ups which means that when the balance on their account goes below a set threshold, their account is topped-up. Kind like the Starbucks card, if you own one.

I timed how much it takes for a payment request to complete, in a synchronous mode, in the test environement. 107 milliseconds. That is pretty fast. You do the math, but there are 86.4 million milliseconds in a day so there's room for over 800K transactions in a day. If your system needs to process more than that, then you are probably in trouble and you would need some kind of load balancing. I doubt that you would have to process such a huge number.

One thing you need to consider is what happens if you fail to save the response in your database or your repository. You need ways to recover, either by voiding that payment or by going in the Authorize.Net system later and get the transaction, because your batches won't reconcile.

Good luck and have fun along the way,

Eddie

[ksanchezssmci1]

Thanks for your response Eddie!  

The numbers you provided are a great help and put me more at ease about my planned process for the recurring billing with CIM implementation.

In regards to making sure I save all the transactions in my own database, I was thinking of creating a separate console app that runs on a weekly basis (maybe more frequently, not sure yet) that reconciles the transactions stored in my database with those in authorize.net.  Looking at the Authorize.Net Transaction Reporting API I would use the GetSettledBatchList, GetTransactionList and GetTransactionDetails methods.

Again thanks for youe response!

-K

[mkienenb]

Well, The basics to create your own recurring payment processor is pretty much what you've got there.

The actual implementation tends to be a bit more complex, but that's just working out the details and customizing it to your own usage patterns.

I've run our own recurring batch processor for 13 years through the AIM gateway.

Switching over to XML and adding CIM payment sources into the mix hasn't been a problem, although we won't really be sure until we go live.   One issue that XML is going to make more difficult is testing.  The AIM gateway had a special card number (42{13}) which you could use to specify any error code by using that error code as the transaction amount.   No longer works in XML, so you won't be able to pre-test all of the weird error conditions that auth.net can return.

Some good design ideas I came up with that have been really helpful through the years.

- Create your database record, mark it as incomplete, process the transaction, update the record from incomplete to success/fail.    Now you're guaranteed to know if some error in the middle left you without a clue whether the transaction was processed.   Anything left incomplete needs further investigation.

- Design your process with the abiilty to retry transactions up to some number of times with a delay between tries.   Intermittent network errors or "please try again in 5 minutes" results are going to happen.   It's better to proactively handle these in your batch job than deal with them afterward.

- Along with this, you might want to have a way to determine for each reason response code whether the error is retryable, requires programmer intervention, requires management intervention, requires customer notification, and what the text of error messages to each of those three should be.

- If a customer might make more than one payment with the same card in the same day, you might want to consolidate those payments to avoid transaction fees.   Our business model tends to have many accounts per one payment method which can be hit in the same day.

- You might want to make sure that your process is reentryable.   If the process errors out in the middle, it would be best if you can simply re-run the process a second time and only pick up those transactions that didnt get processed the first time.   This is also nice not only for multiple runs on the same day but also for those times when a daily job didn't get run for three days and you need to still pick up those three days of payments without having to run it three times and somehow specifying what days to reprocess.

There's probably a lot more that could be said and described, but those are likely the ones you want to plan into the process from the start, at least off the top of my head.

We process records synchronously.