topic Re: options for recurring billing in Integration and Testing

options for recurring billing

RandyN — Fri, 02 Mar 2012 20:27:16 GMT

Hi: I've spent a couple of days reading the API docs and this forum. The forum, in particular, has helped a lot with filling in the blanks.

I'm a programmer in an academic department at a public university in the US. We've been using SIM for several years with few problems. The department administration now want to offer automated recurring billing.

From what I've read on this forum, CIM is easier to implement than ARB. According to the CIM XML documentation, "You must still use the standard API (either SOAP or XML) for some operations, such as creating a transaction. The hosted page only provides functionality for creating, updating, and deleting payment profiles and shipping addresses."

So, in order for the customer to actually initiate or process a recurring transaction, I would need to use the standard (non-hosted) CIM API, or AIM?

What's not clear to me is whether there is some combination of APIs that would allow me to completely avoid handling credit card data on my servers (either storing it or transmtting it), both for updating payment profiles and for performing transactions.

thanks,

Re: options for recurring billing

TJPride — Fri, 02 Mar 2012 21:58:04 GMT

The only protected data is credit card / bank account data. Therefore, only operations having to do with those have hosted CIM popups; everything else can be done with regular CIM. Basically, you create a customer profile using regular CIM - Authorize.net will return the previous profile ID if it detects a duplicate - then open the hosted popup so the customer can add a billing profile / shipping address to the customer profile, then process a charge using regular CIM against the customer, billing, and shipping profiles using regular CIM (if the first payment is due immediately). After that, you'll run an automated script run every day to generate charges as they come due.

Re: options for recurring billing

RandyN — Fri, 02 Mar 2012 22:02:43 GMT

But with regular CIM, the customer who's making a purchase would be entering their credit card number, expiration date, etc., on a form hosted on our server?

Re: options for recurring billing

TJPride — Fri, 02 Mar 2012 22:10:27 GMT

If you use regular CIM to create the billing profile, credit card data obviously has to be collected through your server. It's next to impossible to pass the security scans if you're doing that on a web server, though if you're using a POS (Point of Sale) device that connects directly to Authorize.net and isn't used for any other purpose, it's doable.

Re: options for recurring billing

RandyN — Sat, 03 Mar 2012 00:57:01 GMT

This would be on a web server, not a point of sale device. What "security scans" specifically are you referring to?

So, my questions really boil down to this: is it feasible, with any of Authorize.net's APIs, to do automatic recurring billing/charges without having credit card data reside on, or pass through, our servers?

Thanks for your patience.

Re: options for recurring billing

TJPride — Sat, 03 Mar 2012 06:10:09 GMT

http://blog.403labs.com/post/2056608448/saq-c-eligibility-a-comparison-of-saq-c-v1-2-saq-c

Essentially, you're expected to pass the SAQ-D requirements if you collect credit card data on a web server, which is next to impossible to do. SAQ-C would apply if you're collecting credit card data through a POS device that connects directly to Authorize.net and doesn't perform any other functions (so web browsing on it would be out).

Short answer - yes. You can bypass SAQ-D and SAQ-C requirements by using hosted CIM.

However, SAQ-VT would probably still apply if you're entering the credit card data yourself through the hosted CIM. You're only entirely free and clear if the customer is filling out the online form themselves from their own computer (which I assume is the situation here?)

Re: options for recurring billing

RandyN — Sat, 03 Mar 2012 14:26:23 GMT

"However, SAQ-VT would probably still apply if you're entering the credit card data yourself through the hosted CIM. You're only entirely free and clear if the customer is filling out the online form themselves from their own computer (which I assume is the situation here?)"

Yes, the customer would be filling out the form on his or her own computer. However, what I still don't get is that from what I've read in the docs and on this forum, hosted CIM is not used for the customer to enter info for a specific purchase (credit card number, expiration date, CVV, etc.). Rather it's used to allow the customer to update their own profile (billing address, expiration date, etc.). How (with what API) would they enter credit card info to make a purchase from their own PC, such that their credit card info does not reside in our server or pass through a form that resides on our server?

Re: options for recurring billing

TJPride — Sat, 03 Mar 2012 22:10:29 GMT

There seems to be a failure in communication. CIM sets up customer profiles (unprotected info, regular CIM) and billing profiles (protected info, hosted CIM), which once set up are charged just by passing profile ID's. Under hosted CIM, the form is not hosted by you, it's hosted by Authorize.net and only displayed on your site via iframe popups. Therefore, the credit card information never passes through your server. It goes straight from the entering computer (customer responsibility) to Authorize.net. Authorize.net just sends you back a profile ID to bill against.

If that doesn't get across, I don't know how to explain it better.

Re: options for recurring billing

RandyN — Sat, 03 Mar 2012 23:15:50 GMT

OK; no need to be snippy. Note that I asked essentially the same question *several times*--Can I do this without having sensitive data on my server? I was looking for an answer like, "Yes that's correct, and here's why..." or "No, that's not correct, and here's why..." In other words, I was looking for someone who has more expertise than me to give me a view of the forest first, not the trees. I can read all about the trees in the documentation.

Thanks; this has still been helpful.

Re: options for recurring billing

TJPride — Sun, 04 Mar 2012 00:44:40 GMT

Would it have helped if I just said yes without providing any supporting information?

Re: options for recurring billing

RandyN — Mon, 05 Mar 2012 00:25:31 GMT

It would have been more helpful to say yes (or no), WITH supporting info.

Re: options for recurring billing

kaushik1978 — Mon, 05 Mar 2012 17:48:26 GMT

Hi Everybody,

I am new to Authorize.Net and trying to integrate it with Spring Based Java application. We have requirement to create Recurring billing subscription. I am able to achieve that but i would like to do using the CIM. I need CIM as we will be processing instant payments also and will not like user to enter their CC details again and again.

Is it possible if can create an ARB subscription by referring CIM profile

Thanks in Advance

Kaushik

Re: options for recurring billing

TJPride — Mon, 05 Mar 2012 17:56:00 GMT

ARB and CIM are two different things. You can do recurring payments with both; however, ARB subscriptions run automatically, and doing the same thing on CIM requires running your own automated process (probably cron) to generate the charges. CIM just allows you to charge the customer multiple times without either having to store the credit card info in your database or requiring the customer to re-enter their card every time.

Re: options for recurring billing

bhavanichinna — Thu, 05 Jul 2012 12:30:42 GMT

In ARB, we can specify the option for the "totalOccurence" while making a recurring billing request. I am using CIM recurring billing, the question is where do I specify the "totaloccurence" in the XML?

Please help!

Re: options for recurring billing

TJPride — Thu, 05 Jul 2012 21:10:40 GMT

CIM just sets up a profile so you can charge their credit card more than once without having to pass the credit card information each time. It doesn't actually generate charges for you, like ARB does. You need an automated routine that runs every morning, checks who's due, and generates a CIM charge.