Reply
Highlighted
Contributor
Posts: 10
Registered: ‎01-06-2012
Accepted Solution

CIM API calls now returns the full card number in plain text instead of a masked version

At 6:20pm CT on 3/21/16, calls made to the CIM API started to return the full cardholder's card number in the raw response.

 

We make a createCustomerProfileTransactionRequest call with a customerPaymentProfileID and other information, and now we get back a directResponse that no longer contains XXXX1111 in the appropriate position, but the full card number instead -- something that should never be included.

 

It does the same when we use the sandbox URL.

 

Would like to know when this will be addressed.


Accepted Solutions
Highlighted
Solution
Accepted by topic author sdwebguy
‎03-22-2016 08:30 PM
Contributor
Posts: 10
Registered: ‎01-06-2012

Re: CIM API calls now returns the full card number in plain text instead of a masked version

I never did hear back from Authorize, but according to our logs we stopped receiving the full card numbers just before 3/22 4AM CT. Now we have lots of data to erase!

View solution in original post


All Replies
Highlighted
Member
Posts: 2
Registered: ‎03-22-2016

Re: CIM API calls now returns the full card number in plain text instead of a masked version

I can confirm this happened. We use auth.net also on our site and we store their response strings before we process the orders. There was a short time on the 21st where auth.net's API was responding with full CC #'s, not XXXX####.

Highlighted
Solution
Accepted by topic author sdwebguy
‎03-22-2016 08:30 PM
Contributor
Posts: 10
Registered: ‎01-06-2012

Re: CIM API calls now returns the full card number in plain text instead of a masked version

I never did hear back from Authorize, but according to our logs we stopped receiving the full card numbers just before 3/22 4AM CT. Now we have lots of data to erase!

Highlighted
Administrator
Posts: 24
Registered: ‎08-17-2009

Re: CIM API calls now returns the full card number in plain text instead of a masked version

Thanks for this initial post sdwebguy and the follow up DustinBrettOur internal team identified this issue and resolved it.