Integration and Testing

[jima]

When adding a Customer profile (via CIM), there is an optional CustomerID field, which is nice to have, for linking our system id's to Authorize.net.

So my question is, why isn't there a similar field when creating a Customer Payment profile? Something like a PaymentID (or UserID) that could be used in the same manner, only at a user level.

Example

Customer profile: CustomerID 123

- Customer Payment profile: UserID  100

- Customer Payment profile: UserID  101

- Customer Payment profile: UserID  102

Customer profile: CustomerID 456

- Customer Payment profile: UserID  100

- Customer Payment profile: UserID  101

- Customer Payment profile: UserID  102

Customer profile: CustomerID 789

- Customer Payment profile: UserID  200

- Customer Payment profile: UserID  201

- Customer Payment profile: UserID  202

[Aaron]

Hi @jima,

The merchantCustomerId field (or description field, or email field) is useful for tying the profile to whatever identifies the customer on your end, as well as providing a way to ensure uniqueness.

What purpose would an identifier like this at the payment profile level serve? Do you have a particular use case in mind that would benefit from having an identifier for the payment profile besides the payment profile ID (assigned by us) that's already associated with the profile? Are you actually associating the individual payment profiles with already existing IDs on your end?

I'd encourage you to post this onto our Ideas Forum where others can take a look, contribute feedback, and vote for new features. It would be helpful, though, if you could state a good use case for the feature so that we can assign importance accordingly.

[jima]

Hi Aaron,

I tried to show some examples of if in my question, but I guess they weren't clear enough.

Yes, having an (assignable by us, not Authorize.net) ID at the payment profile level would allow us to tie our own id (that resides in our system) to the profile (just like the customerID field).

Think layers of groups and users. group "A" has 4 users, each with their own form of payment. So, in the Authorize.net CIM system, group "A" is the "Customer Profile", with a customerID of "A", then, within that Customer profile, we have 4 payment profiles (users), each with their own userID (or paymentID if you prefer.)

It would be nice to be able to map those IDs to their associated payment profile in CIM.

Here's a practical example:

Group "Acme" has 4 users, where 2 of the users happen to have the same - very common - name of "Jim Anderson." In our system, we have both Jim Andersons registered and using the system with their unique (to the group/company) userIDs. Now, take that over to Authorize.net... I have a Customer profile for Acme, and I've provided - for internal reference - our compantID to the Customer profile. That's a nice cross-reference piece of info that allows us to tie our system to the Authorize.net system.

Now we get to the payment profile(s) that are found within CIM's Customer profile... We enter in the 4 user/payment profiles to the "Acme" customer, but 2 of those profiles share the same name (Jim Anderson). It would be great if we could provide - again, for internal reference/distinction - our userID to the Payment profile, as a cross-reference piece of info that allows us to tie each user in our system to the Authorize.ent system.

Is that more clear, or just a longer version (and just as unsuccessful) of my previous attempt to explain how it would be useful, even necessary?

Thanks again!

[Aaron]

Yes, that's more clear now. However, I definitely wouldn't recommend using a single customer profile for a group of different customers. That's not the use case we designed for. A customer profile should be unique to a person. That person then can have multiple payment profiles assigned to that one profile, and multiple address profiles assigned to that one profile.

There's no rule that says a single person couldn't have multiple profiles, and each of those profiles would have multiple payment or address profiles. Nor is there a rule that says you can't do what you're suggesting where several users share a profile. However, it seems like a bad idea since you'd have to do so much extra work to ensure that you're not showing the payment information for one user to another user.

What in your scenario is preventing you from just using a unique customer profile for each user, the way the system is designed?

[jima]

Ok, I see your point there...

Our use case is that our software has multiple companies (customers), and each customer has multiple users (payment profiles), and we were thinking it would be good to be able to encase each user/payment profile inside of their parent (customer) umbrella.

To be honest, it seems like (and I'm completely open to being wrong here) Authorize.net's CIM isn't robust enough to house the levels of encapsulated data that we need. At least not natively. Again though, I'd love to be wrong about that. Can someone tell me if/how we might go about encasing our users into isolated groups/customer profiles, while still preventing the viewability of the other users/profiles?

[Aaron]

---

@jima wrote:

To be honest, it seems like (and I'm completely open to being wrong here) Authorize.net's CIM isn't robust enough to house the levels of encapsulated data that we need.

---

It's true that we're not building a heirarchy that has any concept of a "group profile" containing a bunch of sub-profiles. That doesn't mean it can't be used in your scenario, though.

Is there something keeping you from tracking that on your end? For example, in your application that's creating these profiles, is there not a way to keep track of something like

Group A (company called Acme, Inc.) has the identifier of ACME on your end and contains the following customer profiles:

Jim Anderson - Profile ID 12345001

Jane Anderton - Profile ID 12345023

Robert Andelman - Profile ID 12345037

              Robert has two payment profiles, payment profile 987015 and payment profile 987312

Group B (a company called Bamford Industries) has the identifier of BAMFORD on your end and contains the following customer profiles:

Jim Anderson - Profile ID 12345834

Joan Ambleton- Profile ID 12345883

Jerry Angletoe - Profile ID 12345413

              Jerry has two payment profiles, payment profile 987544 and payment profile 987284

Keeping track of the associations on your end would let you do whatever you want. If it makes it easier, you can send whatever you want in that merchantCustomerId (well, up to 20 characters), so why not send a combination of the company identifier and the user identifier for whatever profile you create? (assuming it fits)

For example Joan Ambleton might be in your system with the ID of "JoanA01". When you create her profile send the merchantCustomerId as "BAMFORD-JoanA01". Jerry Angletoe might have "BAMFORD-JerryA07". The Jim Anderson at Acme might be "ACME-JimA02" while the Jim Anderson at Bamford might be "BAMFORD-JimA11"

All that said, I don't want to sound like I discourage your idea. Please, by all means, post it in the Ideas forum. Having more ways to configure something can often enable things that we didn't envision in the design. This is one of those cases.

[jima]

Thanks again for your reply, Aaron.

Yes, I could go the direction that you suggested, I've already been moving in that direction in fact, but that's not the ideal solution as it dual-purposed the merchantCustomerID field, and add unnecessary code and string parsing to get at data that should be fairly straight forward. Having an ID field at the Payment Profile level would make a lot more sense, and would also be a more consistant design structure. There doesn't seem to be a lot of sense of having an ID field at one level but not the other.

As an aside, is there any chance someone can respond to my questions on this other topic?
https://community.developer.authorize.net/t5/Integration-and-Testing/Unclear-basic-workflow-document...