I'm having a lot of fun playing with CIM as a test authorize.net user and it's allowing me to build the website I need to build. I love it. With that said, I have one question. I know how to create all of the proper profile ID's (profile, payment, shipping) but I noticed that if I have 3 payment ID's associated witha profile ID, I don't have one shipping related in any way to a payment id.
In other words, if I have a profile ID of:
I would use
$response = $request-> getCustomerProfile(111111);
I'd notice 3 payment Id's, which is great as I use 3 different test CC's. But the shipping ID's don't really have a relationship with any of those payment id's. I just have 4 random shipping Id's I generated through testing. Since I do not want to store all ID's in a database, is there a way to work saving a shipping ID with a new payment ID so when I pull the entire array of GetCustomerProfile function I can see WHICH address profile id is linked with x payment id?
Or is that not possible? I must have missed something in the markdown examples/documentation.
PS. If this is confusing, just imagine you pull getCustomerProfile but the array returned if you print_r ($response) shows a separate array for Shipping with 4 ship id's but non are associated with payment id keys that are returned. If I need to paste the array I can.
As far as I know, there is no relationship between ShippingID and paymentID in CIM. I think it assume each profileID is for a single user/entity, their shippingID could be shared between different paymentID.
But you could probably do it in your code and database.
I am guessing the best solution is to create unique profile Id's from a customer email and each unique customer profile ID has one associated address/payment id with it. This way there is no risk that they are looking at an incorrect shipping address that they have to re-edit when they choose a payment type during checkout.
That's why I was concerned about no relationship between a shipping and payment id because I don't want to have to store all those ID's if I don't have to (Unless you suggest we do so). I try to store as little sensitive data on the db as possible.
I missed your reply. Ty for the time. Yeah, I could save all profile Id's in the db without an issue so this way when they edit their payment settings securlty in their control panel, at least they are looking at the proper shipping ID and not one of 4 random ones that could be listed. My concern was, is it safe / good practice to store all 3 profile id's for a profile ID? Or do you recommend we store only the profile ID and pull up the payment/shipping manually through CIM?
Thanks. I just want to put security ahead of ease of programming.
This is true. It's a matter making sure FTP is very secure and just using common sense I guess. I will make sure each new
credit card/payment method has a unique profile id associated with our members and then will just log them in the db for ease of us and then focus on securing it all afterward.
Couldn't you just have something in your checkout that lists the shipping profiles and lets them choose which one they're mailing to today? I doubt PCI worries about shipping addresses. Practically speaking, there's no reason why a shipping address would correspond to a billing address, since someone might have several credit cards and have shipping addresses for themselves and a relative they like to buy things for. The relative wouldn't be associated with any of the credit cards.
One thing that caused me confusion was the testing - I created multiple shipping addresses with one profile ID and didn't delete them in the Authorize.net control panel. Basically, since I have a section that lets people use CIM to update their pay profiles, and I want them to be able to choose them quickly, I was concerned that they'd have multiple shipping addresses to choose - I want this as easy to use as possible and having that one shipping profile they could edit/select with payment made the most sense.
I realized that the best solution now is to just create a unique profile id (With payment and shipping id) and store them in the db. This way it's easy for them to edit and there is no chance of them having to waste time reviewing a bunch of shipping addresses/etc.
Thanks for the time. I feel a lot more confident about this process now that I asked this question.