Experiences: Gateways & Tokenization?

[AnySupport]

Hello,

I'm working with a client who is implementing a customized version of AbleCommerce Gold to use as both its front and back end. Tokenization is critical for this project as it was one if the major impetuses of overhauling their system to reduce PCI scope even further.

Early research had indicated that Authorize.NET and Cybersource were supported for tokenization under the use of "Recurring Billing". While the client is not using regular recurring charges, it was believed that this was inclusive functionality. Now I'm not clear if the early research was incorrect.

Auth.Net looks to offer CIM for its implementation of tokenization. This was introduced in R7, which the client did update to now as it would not be a setback for development yet. However, the client is a large enough business to fall outside of Auth.Net's target size and falls under CyberSource's scale.

I'm trying to find answers from AbleC directly, but also hoping people here might be able to add their experiences or help clarify!

1a) Have you implemented Gold (any release level) incorporating tokenization?

1b) Do you know for a fact (implemented or not) if CyberSource's gateway can be implemented with tokenization?

2) Did you try to do so with Cybersource or Auth.Net and hit any impassable or just highly painful road blocks?

3) If you managed to implement tokenization, did the 60 day payment data setting still impact storage of tokens? My client deals with backorders, then a 30 day return policy, so this limit would become a problem. I completely understand its importance with credit card data but for tokens it's purpose is irrelevant.

Any input, resources or experience insights would be massively appreciated!
Thank you!
Liz

[jguengerich]

Let me give you some background on our situation before I answer your questions.

Our site is a private site for our existing customers to order parts. We set up a user in AbleCommerce for a customer, then send them the login info. I'm using Gold R5, because that was the newest version when I started our project. I have made major modifications, both in the site and the source code. This is my first web site of any significance, although I did have .NET (VB, C#) and other C languages experience before this. I did not have ASP.NET experience, so I am sure some of my modifications are not the most elegant or most optimized. Brute force works sometimes when you don't know any better . Because we didn't want to charge credit cards until items were shipped, we were also worried about being able to capture funds when there was a long time between authorization and capture. We decided to use CyberSource's payment tokenization.

Note that there are some terms with various meanings here, so I may be answering something different than what you are asking. What CyberSource calls "Payment Tokenization" refers to setting up a profile (which they also call a subscription) using the customer's credit card info and getting back a token to allow you to make future charges against that card. In my answers below, I will use the term "CyberSource Profile" to be clear that I am referring to this. However, each authorization made using the CyberSource API also returns a field called RequestToken for that specific transaction. CyberSource's docs say it is "...an encoded string that does not contain any confidential information". It isn't used or saved by AbleCommerce's original code (they use the authorization's Transaction Id, also from CyberSource, for captures), but if you save it, it can be used to create a CyberSource Profile.

Now to answer your questions:
1a) Yes (R5).

1b) Yes, we're using CyberSource.

2) I'm not sure I'd say I hit highly painful roadblocks, but it did take quite a bit of work, partly because, as I said, I'm new to ASP.NET. Also, I redesigned the checkout flow to meet our needs (pages and source code), so I was doing work that wasn't directly related to using Cybersource and tokenization at the same time. The Checkout\Payment.aspx page and all the controls it uses (from the conlib folder) is quite complicated (I have not had time to look into the one-page checkout in R7 yet). I did not use the AbleCommerce Recurring Billing because (as of R5) it looked like it was all processed and stored on the store web server, not on CyberSource, and it was geared toward repeating payments, not on-demand charges. The modifications directly related to tokenization in my solution involved adding 2 tables to the database, and modifying/adding quite a bit of code at all levels: page code, source code, and CyberSource integrated provider code. After my first modifications the customer would have still been entering their credit card information on the AbleCommerce Payment page. However, when we started digging into the PCI compliance requirements, we decided that in order to reduce our PCI scope even further we would make use of CyberSource's "Secure Acceptance" hosted page. So now, when our users get to the payment part of the checkout process, they are transferred to a page on CyberSource's servers. After they enter their card information there, CyberSource's server sends them back to our AbleCommerce-based site. Their credit card number, expiration date, and CVV never touch our network or server. The transaction process is as follows: We create a CyberSource Profile at the same time we authorize the charge for the order. If the user wants to save the card information for future orders, they enter a title. When the order ships, we capture the authorized transaction. If that fails (because the authorization has expired), we use the CyberSource Profile to do a new Authorize/Capture transaction. If that fails, we have to contact the customer. After the capture (or the new authorize/capture if necessary), we delete the CyberSource Profile unless the customer indicated they wanted the card info saved. Unfortunately, I can't really give you a good estimate of how much time implementing all of this took. Overall, from first code change to going live, it took about a year, but again, that included learning ASP.NET and making many unrelated modifications to AbleCommerce as well, so I'm not sure how useful that time frame info is.

3) I'm not sure which 60 day setting you are referring to. Because we are creating the CyberSource Profile, we aren't really worried about the authorization expiration timeframe (which is up to the issuing bank and theoretically could be as short as a day or two) or the payment data storage timeframe. We can always do a new authorize/capture (as long as we don't delete the CyberSource Profile). However, if the card expires, or the customer gets a new card, etc., we still may have to contact the customer.

We have only been live for about a month with a few test customers, and only one order has been placed with a credit card (the rest are Net 30). We're kind of waiting to see how many times this comes up in real life to know if it was worth the effort to cover so many bases. Also, since these are existing known customers, there's probably less risk of not getting paid compared to a public web site.

I hope I didn't overwhelm you with information. Also, this is not meant to be a criticism of AbleCommerce. We had some unique requirements I didn't go into that can't be covered by a general purpose e-commerce package. We decided to go with ASP.NET, and AC seemed to be the best starting point for our needs when we compared it with other ASP.NET packages.

[AnySupport]

OK, I'm still working through this, but I wanted to say HUGE thanks!
(I prefer being drowned in information that I can sift through myself than getting a single sentence without context )
I'll reply again if/when I have coherent questions.

Thank you!!

[jguengerich]

One other thing, I haven't looked at Gold R7 at all yet, so I don't know if anything I modified or added is now included "out of the box".