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.

[brianmc]

Hi Shweta,

While we can't give out hard dates I can say it's due to be released very soon (weeks not months).

brian

[martin1b]

Thank you! Please let us know when completed. Our customers are asking for this.

[simeyla]

@brianmc hey Brian. it's been weeks now ;-)

I see you did a new release recently. Did this feature not make it - or did the documentation just not get updated. 

[brianmc]

Apologies for the delay, we had some urgent issues which jumped the release slot queues, for good reasons, however this feature is in the final stages of testing and should be released very soon.  We will be sure to post back here as soon as we release.

Thanks again for your patience,

Brian 

[brianmc]

Hi guys,

Look out for the official blog post in a couple of days time but I did want to let you know that unmasked expiration date is now available.

Simply add the unmaskExpirationDate flag and the exp date will be returned unmasked.

http://developer.authorize.net/api/reference/#customer-profiles-get-customer-payment-profile 

<getCustomerPaymentProfileRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
   <merchantAuthentication>
        <name>your_api_login</name>
        <transactionKey>your_transaction_key</transactionKey>
    </merchantAuthentication>
    <customerProfileId>1000</customerProfileId>
    <customerPaymentProfileId>20000</customerPaymentProfileId>
    <unmaskExpirationDate>true</unmaskExpirationDate>
</getCustomerPaymentProfileRequest>

Brian

[ctdavis]

Today I noticed my calls to getCustomerPaymentProfileRequest did not return customer payment profile objects anymore.  Soap message logs looked okay but deserialized object was null.  

I notice System.Xml.Serialization.XmlElementAttribute(DataType="gYearMonth", Order=1) on expiration date field.  As far as I can see, gYearMonth just means "string," but my issue seemed like object deserialization of customer payment profile SOAP/XML was failing so I wonder if masked value XXXX can deserialize when described with gYearMonth attribute?

Now I pass true for unmask and I get expiration date (YYYY-MM) back in SOAP/XML, and now I get customer payment profile objects again, so my problem today, already fixed via service reference update allowing me to pass true for unmasked expiration dates, kind of almost had to be deserialization of the expiration date XXXX. 

[darrychui]

When will the sdk be updated with this "unmaskExpirationDate" so I can utilize it?  Thanks

[brianmc]

SDKs should be updated in the next 10 days.

Brian

[ctdavis]

Hi, sorry I was pretty unclear yesterday at 7:37pm after a long day of "I did not change anything in my Authorize.Net payment processing for 2 years so why did profile based card processing just start failing over night?"

I had to update my live (and sandbox) service reference(s) yesterday due to production (and sandbox) issues with this API change.  

Until I got the new API and became able to pass a "true" into new param unmaskExpirationDate, GetCustomerPaymentProfileResponse data deserialized to NULL, apparently due to new expiration date value "XXXX" 

Am I really the only Authorize.Net customer whose card processing failed ~simultaneously on live and sandbox due to this change?   

The symptom was (total failure of profile based card processing and then finding) VendorMethodID 0 for every new ProfileMethod being created.  The cause was deserializtion failure reading customer payment profiles, apparently due to new (and unrequested) value XXXX for expiration dates.

Anyhow I already fixed mine, so I am out. Although the new param being "maskExpirationDate" is what would have made sense, now it's too late for that since "unmask" is live.  Please do not change this API again, at least not without plenty of notice about breaking changes.