I'm trying to implement a credit card expiration email notice solution to customers stored in CIM. Initially, we thought that the expiration date was not allowed to be stored even if we are not storing the PAN, so we never stored it. I've since found that the expiration date can be stored.
I've done some tests using the CIM API and the credit card expiration date comes back masked. But, when I use the Authorize.net merchant portal to view the CIM profile, the CC expiration date it is not masked. Two questions:
1. Why is the expiration date vieable in the merchnat portal but not via the API?
2. Is there any way to get the expiration date via the CIM API so that I can send an email to CCs expiring in the near future?
1. This was done for security purposes. We never return the expiration date in any other format other than masked in a response via API.
2. I am not aware of any plans of allowing the retrieval of expiration dates via API for the same security reason.
Thanks for the reply Elaine! Hmm... this will be an issue as it will be difficult to automatically email members when their CC are about to expire. Any suggestions on how we could automate this in some way? Is there a way to retrive this from the ARB API? It is the ARBs that we have setup that need this currently. The only notification we recieve currently for ARBs with expiring credit cards is an email notification. Has anyone else had this issue and found a solution that works?
That is a good idea but I'm still stuck with the current records where we did not store the expiration date or CC notification date. Any ideas how to send notifications for the current records where all we have is an email notification? Anybody know why the CC expiration notices are only sent via email? Why aren't they part of the silent posts? Thanks!
I'd like to know the answer to this too. There is no way to get the expiration dates unless you record them in your own system (or a court ordered subpoena), which up until now I haven't done since we were manually taking care of all the failed transactions. Now I'm using silent post and I need to automate the expired accounts and there really is no way to do it besides setting up a script to parse through the emails.
There is all this protection and safe guarding of data by hiding the expiration dates of credit cards within the authorize.net system, yet to notify us of important things like expired cards they use unsecured email containing a lot of customer data. Name, phone number, address, email, etc etc. If someone got a hold of these emails it would be pretty easy scam... just call my customers up claiming to be from my company and ask them for their updated card info since their old card has expired. All the info they need is right there in an email.
I think I may have a solution but I have not been able to test it yet. What may work is to run a test authorization on a CIM profile on or around the first of the month. If the test authorization fails, then an email can be generated based on the test response. This would require the CIM service to work. For ARB only subscriptions I'm still looking for a solution.
Has anyone tried using the CIM test authorization option to send credit card expiration notices prior to expiration? Any ideas on how to do the same for ARB subscriptions where the CC expiration is not stored locally? Thanks!
So it's been almost 2 years and there apparently is still no functionality within Authorize.net to help facilitate expired credit card notifictions. Authorize.net has stated that they added it to a feature request list but it's clearly not a high priority. Competing payment gateway providers do provide this information for tokenized and/or recurring billing profiles so it's frustrating that Authoize.net has not added this functionality. I can verify that this has, in part, caused two top merchant to move away from Authorize.net.
Another ongoing short coming is that there is no way to connect a CIM profile with a ARB profile. I understand that CIM can and was initially designed to be used to process recurring payments from a client side application but the burden to process the recurring payment requires additional programming or third party tools on the customers side. Having the option to connect and update the ARB profile from a CIM profile would allow developers to use the CIM service as a central payment profile in conjunction with the ARB service. If the reporting to request credit card expiration status or upcoming expiration status was available, it could be used to update both the CIM and ARB.
PCI compliance should allow Authorize.net to return an unmasked expiration date as long as the PAN is not provided. It's frustrating that this is nopt an option. There is an option to download a full tab delimited file of the CIM profiles but it too masks the expiration dates so there is no way to integrate this with a back-end notification system.
Does Authorize.net actually have plans to add additional credit card expiration functinality to the APIs or is it really not considered an important feature and will never be implemented?
Hi All, I was searching through Google to see if Authorize.net had implemented any kind of solution for the exipration date problem yet. Looks like they haven't.
Anyway, here's the unsightly/inconvenient way we've worked around the problem. When a new customer signs up with us, a human being goes into the customer profile and puts the expiration date of the card into the "Country" field of the customer profile. We don't use the country field for anything so it serves as an acceptable place to keep this information.
It's ugly and it's inconvenient, but it at least allows us to email customers who's cards are about to expire.
Hoping for the day Authorize.net implements a solution for this like the other processors have,
Intresting work-around or hack that might be useful in the future. You could potentially do this via the API and using some user defined field. I wonder if this would violate Authorize.net's terms but they clearly are not taking this lack of functionality seriously at this point so I'd try it.
Auth.net has lost a high quantity, top merchant partly due to this issue so they are loosing money and don't seem to care. I know this functionalty is availble in the services of the parent company Cybertrust so maybe they use it as an upgrade teaser but it is ridiculous that this is not avaible in Auth.net. The wait continues for Auth.net to improve their services...