topic Re: Storing Customer Data in Integration and Testing

Storing Customer Data

JohnBoy — Mon, 12 Mar 2012 14:33:05 GMT

Hello, newbie here. I have a dumb question, and I apologize in advance if this is not the right place to ask it - please move it (or tell me how to) if it should reside elsewhere.

We have a customer who has subscribed to Auth.net's CIM service. She says however that when customers are being directed to her payment page (hosted on AN) that the customer data is not being saved, so she has to go fetch it from the customer again if she wants to charge follow-up payments.

Is this something she can configure in her AN account? I'm not sure what else we can do on our end besides send the customer to the AN page to pay... (?)

Any help appreciated.

Thanks,

John

Re: Storing Customer Data

RaynorC1emen7 — Mon, 12 Mar 2012 16:37:49 GMT

Are you sure it is using CIM and not SIM/AIM/DPM?

Because CIM use the saved info to create CC transaction.

Have her check her merchant account and see if there is any CIM data.

Re: Storing Customer Data

JohnBoy — Mon, 12 Mar 2012 16:53:38 GMT

Thanks for the reply.

The source website is doing a simple form post of data to direct customers to the AN-hosted payment page. (Is that what you mean?)

We pass customer indicative data, or at least the portion of it that we need, and these serve as defaults when the customer arrives at the AN-hosted payment page. But they can of course override these. I imagine they also choose what credit/debit card they want to use, and enter that information as well (16-digit number, expiration, and perhaps the 3-digit code on the back). Address verification is configurable in customer's merchant account, is that right?

John

Re: Storing Customer Data

RaynorC1emen7 — Mon, 12 Mar 2012 18:06:27 GMT

Sound like it is SIM and not CIM. Just by signup for CIM is not enough. Need programming change to support it.

The documentation

SIM

and

CIM

Re: Storing Customer Data

JohnBoy — Mon, 12 Mar 2012 18:14:47 GMT

Thanks. But wow, really? A merchant needs thousands of dollars of development work to support a simple customer storage feature? That they are already paying $20 a month extra for?

Why can't AN store the customer info. automatically when customers pay through the simple AN-hosted form?

What if the merchant was manually entering CC transactions into their terminal? Would AN store customer data then?

John

Re: Storing Customer Data

RaynorC1emen7 — Mon, 12 Mar 2012 18:29:40 GMT

It doesn't take thousands of dollars, the sample code/documentation show how to do it already.

It not about saving the customer info, it mainly about saving the customer ID and customer payment profile ID on your end, so it can be access to create new transaction.

There is also the hosted CIM option as state in the documentation.

If merchant enter CC transaction thru the "Customer Information Manager tools"(not the standard Virtual Terminal), then yes it will be save.

Re: Storing Customer Data

TJPride — Mon, 12 Mar 2012 20:00:29 GMT

Agh. If you know what you're doing, it might take a few hundred dollars of time max to implement CIM. And Authorize.net DOES store customer info when you pay through the other API's - it's just not available to you through the API, for security reasons. You can, for instance, go to a transaction in your Authorize.net control panel and create a subscription from it that way. You can also access all the non-credit card details of a person by using the Transaction Details API with the transaction ID.

Re: Storing Customer Data

JohnBoy — Mon, 12 Mar 2012 20:32:42 GMT

Ah - maybe there's something wrong then. We don't need (or want) to access any of the stored data through the API - we'd be happy in this case to just have AN store it, and then when the merchant logs into their account, they would be able to see the CC data and even use it to make further charges. But this would be outside of the merchant's website.

Am I unnderstanding this correctly - if we're just posting to simple AN-hosted payment pages, then AN will store the customer CC data, but the merchant simply needs to access from a different interface than the standard Virtual Terminal?

If so, that could be very helpful until we can develop a more sophisticated solution.

Thanks for the help, I do appreciate it.

John

Re: Storing Customer Data

TJPride — Mon, 12 Mar 2012 21:18:08 GMT

You can not access credit card data directly through the API. Even CIM only gives you a profile ID that you can use to process further charges. The only way to get credit card data is to ticket from your account and ask Authorize.net to dump you a file, which I believe involves a one-time fee. If you want to do multiple unscheduled or variable charges automatically, your only choice is to integrate CIM.

Re: Storing Customer Data

JohnBoy — Mon, 12 Mar 2012 21:44:48 GMT

Ok, but you mentioned that she could go through her Auth.net control panel and create a subscription for a customer, right? Can that be pulled from their previous transaction, that was created by the customer's original payment that they made by being directed to a simple AN-hosted payment page?

John

Re: Storing Customer Data

TJPride — Mon, 12 Mar 2012 23:15:58 GMT

That would be an ARB subscription, and yes, I believe so.

Re: Storing Customer Data

JohnBoy — Tue, 13 Mar 2012 15:25:24 GMT

Thanks. So I have another question (should it be in a new topic?)

When a new customer profile is created, is that profile exclusive to that Auth.net merchant account? Or are the customer ids "global"? We have many customers who use Auth.net (and expect many more), so we're trying to figure out if we need to store the customer id, and if so can we store it globally, or do we need to associate multiple Auth.net customer ids, one for each individual Auth.net customer?

Also, what happens if we create a new profile for a customer with the exact same data?

Thanks for entertaining my annoying questions...

John

Re: Storing Customer Data

TJPride — Tue, 13 Mar 2012 17:31:03 GMT

1) I think it's global, given the size of the customer ID's, but the only way to find out for sure would be to try to create the same person on two different accounts.

2) Authorize.net throws you an error E00039 and also returns the profile ID of the duplicate profile. So you just check for that error and then access the existing profile ID, your process moves on just like if you'd actually created the profile.

EDIT: Regarding 1), how would they distinguish between your duplicates and someone else's duplicates if all the profiles were global? Hmm. On second thought, it could go either way. Need a mod to chime in, or this needs to be tested.

Re: Storing Customer Data

JohnBoy — Wed, 14 Mar 2012 14:31:28 GMT

Good deductions. Also, how would one test this with a single (test) account? I can create as many customer profiles as I want in there, but I can't try it with the same customer data on a second account to verify, right? Unless someone has a clever idea to share?

It would be better still if someone from Authorize.net can tell us authoritatively.

Also - what happens if we try to invoke the CIM api on an account that does not subscribe to CIM? Are we to "fall back" to simple form-posting?

I appreciate the useful feedback, thank you all.

John

Re: Storing Customer Data

JohnBoy — Wed, 14 Mar 2012 17:11:05 GMT

Is there an API or technique that will permit the customer to create a profile and complete a transaction at the same time?

John

Re: Storing Customer Data

TJPride — Wed, 14 Mar 2012 17:45:31 GMT

Accounts without CIM obviously won't support the CIM protocol and will throw you an error saying as much if you try to use it.

Because profiles and transactions involve totally different processes, each with its own set of responses, there is no API or method that allows you to create a profile and charge a transaction all at the same time. Unless by "at the same time" you mean on the same page call, in which case it could be done if you're using regular (not hosted) CIM for managing the billing profiles. If you're using hosted CIM, you have to collect their personal info if you don't have it already, create a profile, display the billing profile management popup, wait for them to finish with that, then go to a checkout page where they can select from their billing profiles using a form select or whatever, so you know what billing profile ID to put into the order. I suppose if there's only one billing profile, you can skip that last step and go straight to generating the charge.

Re: Storing Customer Data

JohnBoy — Wed, 14 Mar 2012 20:13:54 GMT

Yikes. That's too bad. Bookerville's process really needs a super-lean and streamlined payment for end customers. Our vacation rental managers like to collect a down-payment of sorts for the rental, which is calculated and shown during the booking process. Right now, customers are shown a nice, simple, obvious button to click which takes them to an Auth.net hosted page where they fill out their details, enter their CC information, and pay. Very simple, very clean, very effective, most people do not get confused.

It's too bad AN can't just create a profile at that time and store it for the merchant, passing the new ids/tokens in the callback (and Silent Post), all without Bookerville having to implement this very tedious CIM process. I am at loss to understand the security issues around that? I mean, I understand if you're a Merchant-Hosted site trying to implement a (nearly) full-featured virtual terminal, but goodness that's not what we're trying to do. It would just be very nice if merchants could sign in to their accounts and be able to pull up credit card data for previous customers, without having to tell AN to do it through this convoluted api.

John

Re: Storing Customer Data

TJPride — Wed, 14 Mar 2012 22:54:15 GMT

Well, that might make implementation a bit simpler, yes. However, I don't think it's going to put people off -that- much, especially if you work in some AJAX so the number of page loads is reduced to a minimum. Either way, it is what it is, I have no control over the interface.