Membership Site (Recurring Payments) - AIM & ARB?

[olimits7]

Hi,

I currently have an ecommerce shopping site using Authorize.Net with AIM.  Using AIM with an ecommerce site is simple because I just "authorize" and then "settle/capture" the amount when the item ships.

However; I'm working on a new site which involves recurring monthly/yearly membership fees as well as still using an order type checkout process like an ecommerce shopping site.  The ecommerce checkout proces would be simple because I can just use the same AIM type method to process orders that I currently use on my live ecommerce site.

But I'm at a loss, on what the best method would be to process the recurring monthly/yearly membership fees. 

One method I was thinking of using, but don't know if it makes sense, is when the customer signs up for an account that would be the "billing date" I will use for the next payment due.  For example,  at the time of signup I would charge a "one-time setup fee" along with the "1st month payment".  So if the customer signed up on 2/15/12, in the admin part of my site under a "Recurring Payments" page I create; I would list all recurring payments with the "amount due" and the "next bill date".  So when 3/15/12 comes around I was thinking I could use a "cron job" that runs daily on my site to send and charge any payments that are due on 3/15/12 to Authorize.Net using AIM.

Would this make any sense at all to use this method?  Or would I be able to handle this process better using ARB?

I never used ARB so I'm not sure how or where I would fit using ARB into my website to handle recurring payments.  Would I still need to create a "Recurring Payments" page in admin like I described above?

Thank you,

olimits7

[TJPride]

With things getting more and more restrictive, it's really a bad idea to store credit card data on your end, which you'd have to do if you were to implement recurring payments using AIM. Since ARB can't do the first charge immediately, the method most people use is to charge the first payment via AIM, then on that same page set up an ARB subscription using the same card info and so on (if the AIM charge goes through, you know the card is good...), with the first payment of the subscription a month from now or whatever. Using ARB does mean integrating silent post, however, which is a page that sits outside the charging flow and gets a post from Authorize.net whenever a transaction goes through. All in all, if you're familiar with AIM, it's probably easier to integrate CIM, which has essentially the same charging procedure as AIM and only differs on setting up and managing profiles. If you're using PHP, you can get some excellent code examples by looking in the doc folder of the SDK for a file called AIM.markdown. Or read the CIM documentation and look at the sample code if you want to implement hosted CIM:

http://www.authorize.net/support/CIM_XML_guide.pdf

http://developer.authorize.net/downloads/samplecode/

[olimits7]

Thank you for your reply!

Would the following workflow/logic work?

1. User signs up for an account; using AIM the total amount (one-time fee + 1st monthly payment) is "authorized only" and set to "pending" status.

2. If successful authorization is received:  The user account info is manually reviewed; and once approved the total amount is "settled/captured" with AIM and at the same time with a "silent post" a ARB subscription is created with next month's payment date for the "membership fee".

When next month's payment is charged successfully; will I be able to save the response data back to my site?  I want to create an "invoice history" page for the customer so they can view the membership amount and date of each of their monthly recurring payments.

I took a look at the CIM guide:

- Using the "standard API" I would still be able to use my website's layout/design and send this information to Authorize.Net from within my website and make it look seemless with my site; right?

- Using the "hosted API" I would be able to use an iframe so it looks like the form is from my website; right?

One thing I don't like about the "hosted API" iframe is it looks very generic; would I be able to tailor the form to match my website's design layout and also remove "powered by authorize.net"?  I want to use a seemless integration method so it doesn't look like the customer ever leaves my website; this is why I like using AIM.

Also, I setup a Authorize.Net sandbox account:

- and I see under the ARB section that it doesn't ask for the CCV#; why is the CVV# not requested when setting up a new subscription?

- and I see under the CIM section that Authorize.Net doesn't ask for the CVV# as well?  and I can't seem to find any fields relating to setting up a recurring payment; can setting up a recurring payment be done from within CIM or is this only done with ARB?

Thank you, again!

olimits7

[TJPride]

The only time you have the credit card data when using AIM is at the initial transaction. So you're going to have to set up the ARB subscription then, not when the AIM transaction is captured. Given, you can set up an ARB subscription manually through your control panel, so if you're capturing transactions there as your products ship, you may as well just take the extra time and set up a subscription. Unless, of course, your products are low dollar and high volume and you don't want to bother.

You can set up a silent post page that Authorize.net sends a post to for every transaction (whether through, AIM, ARB, your control panel, etc.) Assuming your ARB subscriptions have a member ID or some other way to identify them as ARB subscription charges when they come through, you should have no trouble recording transactions. I do this with one of my client sites.

As for the hosted CIM, there's not a whole lot you can do to customize the look. If you want to integrate 100% seamlessly, you can always use regular CIM, which has the same PCI scope as AIM (the card data passes through your site, but isn't stored) and works largely the same way. You can see sample code for that in the CIM.markdown file in the doc folder of the PHP SDK. It's pretty intuitive.

The CCV# is not asked for with ARB because the CCV# can not be stored, even by Authorize.net, and since the first charge is not made immediately, there is therefore no point in asking for it. Most people use AIM to do the first charge and validate the credit card, from then on it's assumed to be good until it fails.

CIM does not have recurring payment support. All it does is store the billing data so you can charge the card yourself internally without having to either store the card data or having to ask the customer to re-enter it every time. You'd set up the recurring payment process yourself by having an automated script run every morning and check your database to see if anyone's due. If they are, you bill their profiles for the amount due.

[olimits7]

Oh ok, I checked my Sandbox account and I see what you mean of how I can setup an ARB under the transaction detail manually by using the "Create ARB Subscription from Transaction" link.  This is one method I could try, but I want to automate this as much as possible.

My site will allow customers to change between "monthly" / "yearly" billing cycles; so I will need to be able to give prorated refunds based on the unused days. 

I guess I can use either ARB or CIM to manage recurring payments; so some options that I see I can use are:

Option 1: Use AIM, store encrypted credit card data, be PCI complaint, and use ARB for recurring payments. 

When user submits account info "authorize only", manually review (check AVS/CVV responses), if account info is ok approve and "capture/settle" one-time fee and 1st membership fee using AIM.  Then for recurring payments and dealing with prorated refunds; I guess I would use AIM to issue the prorated refund, and then I would need to cancel the current subscription and create a new subscription by running a "cron job" script from my site.

Option 2: Use regular (standard) CIM, save customer profile ID (payment, billing, shipping), and use CIM for recurring payments.

When user submits account info "authorize only", manually review (check AVS/CVV responses), if account info is ok approve and "capture/settle" one-time fee and 1st membership fee using CIM.   Then for recurring payments and dealing with prorated refunds; I guess I would use CIM to issue the prorated refund, and then I would also use CIM to charge the recurring membership fees by running a "cron job" script from my site.

I like "option 2" better because I don't need to worry about being PCI complaint or storing credit card information, but I have some questions about CIM.

1. Based on looking at the "CIM_XML_guide.pdf" guide, it looks like I can do a transaction to "authorize only" and then later "settle/capture" the transaction?

2. I also see that I can ask the user for their "CVV" code at the time they submit their account information; which is good!  So would I be able to receive the same AVS / CVV responses from CIM like I do with AIM?

3. I will like to have an account page where customers would be able to "add/edit/delete" payment information. 

a. Would I be able to show my customers their currently saved billing address using the "regular (standard) CIM" API?  If so, would they be able to "add/edit/delete" this on my website if I use "regular (standard) CIM"?

b. Basically, the same question here but dealing with the credit card information.  From researching this forum, I see that I would be able to show the last 4 digits of the credit card number; which is fine.  But it doesn't seem like I would be able to show the expiration date info; right?  If this is the case I think I could save the expiration date in my database; since I don't believe this goes against PCI.

4. I will still like to save the billing/shipping address on my website; I don't believe this goes against PCI as well.  But when my customer saves this information using the "regular (standard) CIM" API; can I also update at the same time my database copy when they make any "edits/deletes/adds"?

5. From reading the following post, I also see that CIM is not as easy to integrate as AIM would be.  I see that their are issues depending on the ordering of fields in the XML, and others issues that this user points out.  So I wonder if it's worth trying to implement CIM if it is a pain to do?

http://community.developer.authorize.net/t5/Integration-and-Testing/CIM-Gripes-and-Suggestions/m-p/4...

Thank you,

olimits7

[TJPride]

1. Yes.

2. Yes.

3. Correct, except expiration date is a protected value and can not be stored either if you want to avoid complicated PCI.

4. You can store anything outside of their credit card, bank account, etc. info on your end, meaning the billing / shipping address is fine. And if you're using regular CIM, as opposed to hosted CIM, you have the new data every time they do an update, so it's easy to mirror the changes in your db.

5. CIM is somewhat harder to implement than AIM (though not very if you use an API and don't have complicated needs). However, AIM is totally incapable of doing PCI-compliant recurring billing, so it's either CIM or ARB, and ARB is in my opinion worse than CIM. Just implement using an API and you should be ok. I use the PHP API myself.

[olimits7]

Thank you for your quick reply!

Ok, I'm surprised that Authorize doesn't let you pull and show the expiration date from their servers using CIM.  I guess I could just show the masked expiration date, but still give my user the ability to update the expiration date if they need to through my website using the "regular (standard) CIM" API.

One thing I don't understand is if CIM can basically do everything and more than AIM; like save customer profiles (payment, billing, shipping), submit initial "authorize only" transactions, and then be able to "settle/caputre" these authorizations later, receive AVS/CVV responses, decline a transaction if it fails your AVS/CVV settings, handle recurring payments without the need for ARB, etc...why would anyone want to use AIM in the first place besides CIM charging a monthly fee to use?

http://developer.authorize.net/api/

And I don't understand why Authorize.Net has CIM listed under the "product APIs" section on here; AIM also has their own API as well.  I would think they would list CIM under the "card not present transactions" section, since it easily compares directly with AIM, SIM, and DPM?

Thank you,

olimits7

[olimits7]

Also, if I'm using CIM to do the first initial "authorize only" for the "one-time fee" and "1st membership fee"; I will need to have my script first run the "createCustomerProfileRequest" function to save all the filled in customer profile data, and then immediately after run the "createCustomerProfileTransactionRequest" to "authorize" this transaction?

Thank you, again!

olimits7

[TJPride]

Correct. Incidently, if you could pull expiration date from Authorize.net using the API, then the billing profile ID would also become protected and you wouldn't be allowed to store that either. It's the concept of tainting - anything that touches a protected item becomes protected as well.

[olimits7]

Ok, thank you!  Regarding my previous question:

If I'm using CIM to do the first initial "authorize only" for the "one-time fee" and "1st membership fee"; I will need to have my script first run the "createCustomerProfileRequest" function to save all the filled in customer profile data, and then immediately after run the "createCustomerProfileTransactionRequest" to "authorize" this transaction?

Thank you, again!

olimits7