UnMasked Expiration Date in Hosted CIM's getCustomerProfileRequest

[CoryAuth]

As mentioned in the following post:

http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted...

The card expiry date is masked when returned in the getCustomerProfileRequest.  As the card number is masked, there is no PCI requirement that the expiry date of the card also be masked.  Without the expiry date, it makes it impossible for us to automate the process of notifying our customer's clients that their card will be soon expiring.  The reason for us going this route is to offer an ARB solution managed completely from within our application.  It is imparative for us to have access to this date.

The idea is a simple one.  Return the expiry date in the CIM getCustomerProfileRequest unmasked.

Thanks.

[Rockster160]

Agreed. We would like this ability as well. It's not game breaking, but if it doesn't affect the PCI compliance, then why not make it available?

[atchuthan]

I agree.  We have a similar case to send card expiration to clients using our OpenERP/Odoo ERP system and be managed with it.  

[PatCowgill]

Agreed. We also need to know if a card has expired or about to expired before using it for a payment.

[Salteris]

One major argument for this to be implemented is, according to this PDF regarding PCI Compliance (linked by simeyla here), the Cardholders Name is under the same protections as the Expiration Date and Service Code (irrelevent). The Card Type isn't even mentioned (and commonly known to have no restrictions). 

Given this, if the CIM is returning the Cardholders Name, those at Authorize.Net are either:

a) Failing in thier own PCI Compliance by returning data that they know, by implying they are masking the Expiration Date becuase of PCI Compliance, they should be masking.

or 

b) Making an internal descision to mask the Expiration Date and Card Type for no apparent PCI Compliant reason other than a C.Y.A. scenario. 

This is a service, that people, companies, are paying Authorize.net to make PCI Compliance easier to manage. This isn't easier. This makes data storage redundant, development duplicitous (changing the expiry date off by a month and renaming it?), and the whole service seem much less palatable to larger corporations.

And it's been going on for months (years)? Unacceptable.

Edit: Most up to date guildelines, page 8, same table. https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

[maccamacca]

This is a bit of a joke really, no reply from the developers either.

This is a must have feature, we are already looking at other payment gateways now.

[centsman]

Seems a bit useless to post, but I too need this functionality.  As eCommerce has grown, its only expected that we do a good job notifying our clients of about to expire cards...

[RichardH]

Thanks for your feedback and upvotes.  Our next scheduled internal review of ideas is rapidly approaching.  Keep them coming.

Richard

[RichardH]

We'll soon expose card expiration dates for payment profiles.  As we receive more information from the product team, we'll post here.

[brianmc]

Hi guys,

Brian here, PM for the Authorize.Net API.  This update is in the works right now.   I want to share our plan and get your feedback.

Once we introduce the feature the existing response for GetCustomerProfile & GetCustomerProfile will be unchanged UNLESS you send in the new flag maskExpirationDate set to false.  If you do that the response will have expirationDate field unmasked.

We chose not to default to the new behaviour so that existing clients who may display the expriation date or use it in a manner where they want masked values would not be broken.

Let us know your feedback and thanks for upvoting this feature and helping us improve our API.

Brian

[svidyarthi2015]

Hello Brian/AuthorizeNet Team,

Do you have any idea by when this maskExpirationDate would be released?

We need this feature in our product.

Thanks,

Shweta