cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

options for recurring billing

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,

 

RandyN
Member
1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

14 REPLIES 14

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.

TJPride
Expert

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?

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.

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.

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?)

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

 

 

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.

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.

 

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