Storing Customer Data

[JohnBoy]

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

[TJPride]

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

[JohnBoy]

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

[TJPride]

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.

[JohnBoy]

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

[JohnBoy]

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

John

[TJPride]

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.

[JohnBoy]

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

[TJPride]

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.