CIM createCustomerPaymentProfileRequest duplicate entries problem

[augie]

Accoring to the CIM guide at http://www.authorize.net/support/CIM_XML_guide.pdf PAGE 105 under "Duplicate Profile Verification",  when adding a new payment profile using "createCustomerPaymentProfileRequest", if the payment profile information is the same as a payment profile already in the customer profile, "then the payment gateway will return an error that contains the ID of the already-created profile." As far as I've been able to test, it does not work like the documentation states at all. All I receive back is "Error E00039 A duplicate customer payment profile already exists.", but I do not receive the crucial payment ID of the existing matching profile.

I absolutely need to get this existing payment id returned as there is no other way for me to compare newly entered CC info to a customer's existing profile because all CC info is masked out. (Customers do not [yet] store profiles in my system, but on certain recurring delivery orders, I first bill using AIM for the 1st transaction, then store their info in a CIM profile for subsequent transactions. If a customer returns and starts another recurring delivery order, they enter their CC info again, it will be billed via AIM, then go to CIM. If the payment already exists, I want to use the existing payment ID. If not, create a new payment profile.)

Augie

[augie]

Judging from the lack of responses I guess this issue is just another oversight. First ARB wasn't sufficient for the task and now CIM.

[SteveMay]

Hi Augie,

Ah... you're right, Authnet does not return the id of the Payment Profile you attempted to duplicate, but what do you mean 'it will be billed via AIM, then go to CIM'? This does not make a lot of sense to me. Am I missing something? 

If you are using AIM for recurring billing, why are you fiddling with CIM?

On the other hand, if you saved their profile info last time, you should know what their ProfileId and PaymentId are when they are authenticated/logged in this time, as the data is (should be) readily available. In a nutshell, if your customer is not logged in or at least identified somehow, you're not going to get this to work the way you seem to trying to do it.

On the Gripping hand, if you do NOT know their profile id and payment id, then it sounds like you are trying to set up or use CIM profiles for customers who are not authenticated/logged in, have not agreed to allow this, and/or do not know you are doing it.

Bad idea, IMHO.

It almost sounds like you are trying to sneak up on CIM and it's not working too well. Perhaps you need to get your CIM solution fully operational and then implement it? I can't imagine CIM working at all well if done in half-measures.

hth,

Steve

[hotslots132]

"Gripping hand", eh?  A Niven fan, I think...

I sort of understand where Augie is coming from.  On my store, I allow customers to save their credit card details for future purchases, using CIM.  If however they have previously saved a card, and then check out entering the same card number but then saying "save this", I'd attempt to create a new payment profile with the same details and get an error.  So what are my choices?

1. Get a list of all of the customer's payment profiles (I can do that) and try to guess which one it is based on the last four digits of the card number (and the expiration date since I save that separately)
2. Delete the existing profiles before storing the new one
3. Give the customer an error without real guidance as to what to do about it

At the moment, I allow customers to store only one card, so I take option 2.  I could also update the existing profile.

This gets back to one of the gripes I listed in my first post here - CIM is only half-done.  It is missing key APIs for a robust implementation, forcing merchants to limit functionality or jump through hoops just to try to maintain a good user experience.

[jlanawalt]

I was also hoping for the duplicate profile verification to return the id of the already created profile. I just did a test in a CIM development account and see that customerPaymentProfileId is returning zero instead when I present an exact match.

I was envisioning the case where a customer adds a "new" payment that wasn't really new, it would be nice to have that customerPaymentProfileId right away after the failed CreateCustomerPaymentProfile, as documented, rather than trying to guess which one matches.

Thanks,

Jacob

[SteveMay]

Boils down to basic philosophy, I suppose.

I wondered if anyone would comment on the 'Gripping Hand' reference. :-)

I am not crazy about even considering CIM unless the customer has done something overt to identify themselves, which means they have logged in and authenticated in my book. At that point we know their Profile ID, and we know what their Payment/Address ID's of record are.

From there on out the customer is allowed to make decisions about which profiles to use, updates, creating new profiles or other 'stuff' as determined by the main system code.

I realize that a lot of sites apparently use cookies to id returning customers, but that makes me nervous. In fact it's one thing that truly bugs me about Amazon.

Yes it's easy, but another big northwest company has shown us what happens when 'making things easy' takes precedence over security......

Anyway, thanks for the thoughts from you folks. It's always interesting to see what other people are thinking.

Steve

[augie]

Hi Steve, thanks for the reply!

>> it will be billed via AIM, then go to CIM'? This does not make a lot of sense to me. Am I missing something? 

>> If you are using AIM for recurring billing, why are you fiddling with CIM?

AIM, not ARB. So here's how it works:

1. Customer logs into the website to place an order [edit: They must log in with username and password - I do not allow unauthenticated customers to order]

2. No customer profiles are stored or accessible by the customer. (I'm working with an off the shelf e-commerce system and I'd have to do quite a lot of recoding to implement stored payment profiles/management so I'll save that task for later.)

3. When a customer checks out, they must enter their CC info each time.

4. If a customer orders using the "recurring delivery" option, the order goes through a 2-step process on checkout. First, the order is verified and charged by AIM. Then if the AIM charge is successful, the system will set up a customer CIM profile and store the CIM profile ID in the customer record for future purchases. At the same time, it creates an entry in my "subscriptions" table which stores the CIM payment profile ID and details of the order. Each billing/shipping period (after the initial order), the system will create a CIM transaction using the stored CIM customer & payment profile.

5. THE PROBLEM:  Say the same customer comes back and decides to place another "recurring delivery" order. I already have their CIM profile ID stored, so I don't have to create that again. I also have their previous CIM payment ID stored, but the customer must reenter their billing info each time. If they use a different card as the last time, I can create a new payment ID, but if they enter duplicate payment info as the previous time, the system will error. I was planning to detect the duplicate error, then grab the payment ID from the error and just choose it instead of creating a new one, but like I said, it doesn't return the ID of the duplicate when it errors out.

I only chose CIM because I could do my periodic subscription billing without having to store sensitive customer information locally (except now it looks like I'd have to store CCV, as evil as that is, in order for CIM to bill in an automated manner as the client has CCV verification required on teh account).

I fell like I'm out of options with CIM. It seems to me the only way I can possibly proceed with this is to dig in a spend a large amount of time trying to add customer payment profile management to the e-commerce system.

My reference to ARB was a completely separate problem. I'm getting frustrated working with Authorize.net's APIs that seem to ONLY work in one narrow way of development. I had previously set up the entire system to use ARB for recurring billing, but backed out after doing 95% of the development when I ran into other major problems with that system and realized I couldn't rely on it for 100% automated handling without the possibility of missed billing notices due to server outages (on my end).

Thanks!

Augie

[augie]

I forgot to mention, another aspect of the problem: If a customer sets up 2+ subscription "recurring delivery" orders at different times, I must retain the payment profile of each. I cannot just delete the old payment profiles (as another poster mentioned) and start a new one because the 1st "subscription" must charge 1st CC, the 2nd "subscription" must charge the 2nd CC and so on. If I delete the profiles and make a new as a quick and dirty way to get around it, all the subscriptions will have to be updated to use only the newest card.

I'd be fine just adding new payment profiles each time until I hit the 10 profile limit, but when I post a duplicate, I error out and there's no way I can identify which payment profile id it matches to.

Augie

[hotslots132]

The best suggestion I can offer is to generate a "customer ID" that is guaranteed to be unique for each transaction.  That way there won't be a duplication.  That's how I'm handling the issue.

[augie]

Thanks! I did think of that, but wasn't sure if it was a good solution. According to the CIM guide, various fields are matched to see if the customer profile already exists: merchantCustomerId, description, email. All I can think of is passing a GUID to the description field to throw off the checking. How did you handle this?

Augie