cancel
Showing results for 
Search instead for 
Did you mean: 

ARB - Use AIM or SIM/CIM?

I just started looking at Authorize.Net so before I go too far I would like to know my options for handling subscription payments that may change over time. I will be offering a service that will have tiered monthly features/rates, for example Free, Bronze ($10), Silver ($20) and Gold ($30).

 

Hopefully a customer would want to upgrade, let's say from Silver to Gold, and then I would want to update the subscription to charge $30, up from $20. Ideally this would be an automated, no hands process. Also, ideally I do not want to get involved with PCI compliance if I can avoid it.

 

I do have have programming expertise so AIM/ARB would be an option but to what extent would I have to conform to PCI?

 

What about SIM/CIM? Is there a way to use it for my purposes?

 

Your help is appreciated.

 

Ray

linkattach
Member
2 REPLIES 2

ARB allows you to update the amount using nothing but the subscription ID, and there's no way to get the credit card information back out from the programming side of things. So it's perfectly safe from a PCI compliance perspective, so long as the initial information is collected through a secure page, and so long as nobody gains access to your hosting account. AIM is just your standard one-time payment. I've implemented both using the PHP API. CIM, on the other hand, is a customer information manager, meaning some of the information can be pulled back from Authorize.net (hopefully not billing info, but I haven't tried it out yet...) if you have the customer ID. CIM gives you more control over things like varying term lengths (since you trigger all charges) and has the advantage of not requiring the credit card info to be re-entered whenever there's a one-time fee.

TJPride
Expert

The CIM API does not permit credit card numbers or expiration dates to be retrieved in plain-text. Credit card numbers are returned in XXXX1234 format (where 1234 are the last four digits of the card number) and expiration dates are completely masked (XXXX).

 

So, you shouldn't have to worry about PCI-Compliance issues (at least to any extent greater than what's already been mentioned).