Hello,
I am trying to understand how our CIM database on Auth.net has ended up with duplicate Profiles where the CustomerID has the likeness of a legitimate ID that we have provided, but has appended characters to the end of the ID string.
For example, if we have supplied the unique ID of 12345 for Customer ID (aka Customer Merchant ID), I see the following listings in the CIM when CustomerID = 12345 is searched:
12345
12345a
12345b
12345c
...
12345aa
I have noticed this situation when searching for the ID I used during development and testing. Regardless, I have noticed how these additional records were generated versus being rejected when duplicates requests were probably generated. I have no mechanism that would append characters like this. I have to assume that CIM is doing it....but why? I t should have returned a Code 000039 error instead of (apparently) chagning the ID to avoid the error.
For reference, we are only supplying this one field (of three) during the Customer Profile creation request.
Can someone shed some light on this?
Thanks
Jonathan
Solved! Go to Solution.
โ08-05-2013 09:51 AM
Thanks for the reply.
Here's some additional information which might provide a clue...
The 30 or so affected Customer Profile records have Token numbers in the range 1689XXXX. We are now in the 7XXXXXXX range. I could not find a timetamp on these records within CIM, but it had to be a long, long, long time ago.
I'm going to declare "false alarm" on this one and thank you for helping me clear the cobwebs from my memory. It is very well possible that I might have purposefully generated this set of records for some reason, perhaps for a throughput experiment.
This is the best answer possible. ;-)
Jonathan
โ08-05-2013 11:32 AM
I tried it on the test site and it didn't do that. Are you100% sure, it is not appending in your code?
โ08-05-2013 10:58 AM
Thanks for the reply.
Here's some additional information which might provide a clue...
The 30 or so affected Customer Profile records have Token numbers in the range 1689XXXX. We are now in the 7XXXXXXX range. I could not find a timetamp on these records within CIM, but it had to be a long, long, long time ago.
I'm going to declare "false alarm" on this one and thank you for helping me clear the cobwebs from my memory. It is very well possible that I might have purposefully generated this set of records for some reason, perhaps for a throughput experiment.
This is the best answer possible. ;-)
Jonathan
โ08-05-2013 11:32 AM