Reply
Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Storing Customer Data

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

Contributor
Posts: 12
Registered: ‎03-12-2012

Re: Storing Customer Data

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

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Storing Customer Data

[ Edited ]

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.

Contributor
Posts: 12
Registered: ‎03-12-2012

Re: Storing Customer Data

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

Contributor
Posts: 12
Registered: ‎03-12-2012

Re: Storing Customer Data

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

 

John

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Storing Customer Data

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.

Contributor
Posts: 12
Registered: ‎03-12-2012

Re: Storing Customer Data

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

Posts: 1,609
Topics: 15
Kudos: 201
Solutions: 121
Registered: ‎06-23-2011

Re: Storing Customer Data

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.