What values determine duplicate CIM payment profile on sandbox and production?

[calebpitman1]

On the sandbox, Payment Profiles can be created using the same PAN, but it must have different expiration or it will return duplicate error.

Q1) Will the production environment return duplicate error because it has the same PAN, or will it create a new profile because it has a different expiration?

Q2) Can two different customer profiles use the same card on production?

[Lilith · Accepted solution]

@calebpitman1 In answer to your questions:

A1) We perform duplicate checks on the PAN, but not expiration dates. Part of this is because we are working on adding Visa Account Updater support, at which point expiration dates may be updated regularly.

So if you're creating a payment profile under a given customer profile, and use the same PAN as another payment profile for that customer, you'll get a duplicate error.

A2) Yes, because the duplicate check is per customer profile. So you could have two customer profiles for a couple, and each can have a payment profile that uses their shared PAN.

I hope this helps!

[psys]

@Lilith Is A1 still the case?

We had some tests start failing last week, and upon further investigation, it appears the expiration date + PAN must be the same for a duplicate to be returned (at least in the sandbox).

Commenting out the part of the test that changes the expiration date makes our test for returning duplicates pass again.

[Lilith]

@psys I'm looking into this now and will follow up once I know more. Thanks.

[Lilith]

@psys I confirmed there was a recent change in functionality, so that we're checking expiration dates as well as card numbers.

The idea is that, if a merchant updates an ARB subscription with the same card number, but a different expiration date, it will create a new payment profile.

We'll work on updating our documentation, accordingly. Sorry for any confusion this may have caused.

[psys]

Unannounced funcationality changes like this are one of the many reasons that people dislike working with the Authorize.net api. I know you guys have a changelog, but nothing compared to what Stripe offers:

https://stripe.com/docs/upgrades

[Lilith]

@psys Thank you for the feedback. I agree that we should start including system changes that impact API users, and not just changes to API calls, in the API changelog, and I've conveyed that to our developer team for consideration in the future.

[psys]

@Lilith I wish you would also pass on this incredible undocumented 'feature' of the sandbox api (maybe prod, idk): https://community.developer.authorize.net/t5/Integration-and-Testing/When-posting-test-transaction-2...