Integration and Testing

[WHeisenberg]

I've been struggling with the fact that there is no way to find out (in advance of a purchase attempt) that a customer's CIM record for an individual credit card has an expired expiration date.

Here is the solution I'm considering:

When a customer is about to make a payment,  BEFORE we bring up the payment methods they have stored in the CIM,  we request that the CIM system give us all of that customer's payment profile records.

We then loop through them all, performing an 'authorization only' transaction on each of them.

For the one's who come back with a failure code (response 3 and reason 8) we will know that card is expired, and we can tell the customer that that individual card is on record, and not allow them to use it until they go change the expiration date using the Hosted CIM system.

For the one's who come back ok,  we allow the customer to use that particular card immediately.

This would eliminate any potential transaction failures due to expired cards, because we are filtering them out before the transaction actually takes place.

This also means additional transaction requests will have to be sent to the server (no sweat off my brow, but it is additional processing at the AuthNet end for something that would be so SIMPLE to fix).

Here's my suggestion on how AuthNet can fix this:

Change the way the results of the getCustomerProfileRequest call come back.
If a card expiration date is still valid at the time of that call,  just keep sending 'XXXX' back to us.

However, if the card is expired,  send us 'YYYY' (or something other than 'XXXX') so we - at the very least - know that the card is expired and we wont have to run an actual transaction request to find out if it is.

Returning something other than 'XXXX' would also allow us to periodically (first of every month) run all of our CIM customer records to see if any cards have expired, and send them a message.  Card comes back with YYYY and we can shoot an email to the customer to remind them to change it.

Doing it this way also reduces both our coding needs, as well as the AuthNet servers processing needs.

If a customer has 3 different payment methods on record - in order to validate them all (currently) as having non-expired expiration dates, we would have to run an authorization request for each one individually.

If we got back anything other than XXXX using the getCustomerProfileRequest call,  we could find out the same information with one API call, because ALL of the customer records are returned in the single response.

By changing XXXX to YYYY if the card is expired, AuthNet will still be masking the actual number,  but we'll have something we can actually USE coming back in that field.

This doesn't exactly solve the problem of being able to send a customer an email when their card is 'about' to expire.. but at least it would completely end the need to deal with transactions being declined due to expired dates.

:)
WHeis

[WHeisenberg]

One more thing.  I just discussed my current solution with someone and they said that by running an authorization request against every card on record (whether it is a single card or multiple cards),  I may end up having to pay individual transaction fees on those requests.

I haven't determined whether or not this is the case, because I just write the code - not run the billing department . 

Will an authorization-only request end up costing us money to run?    If so, then I guess it's back to the drawing board for another solution..

Thx,

Wheis

[TrendyTim]

I cant be certain but ive been told by the person that pays the bills around here that if you void a transaction it doesn't cost you anything, but if you dont void it itll cost you like 10cents or something.

You can also store the expiration dates in the database, everything i have read about PCI says you can store exp dates IF you are not storingt he account number (which we are not, as that is the point of CIM)

[WHeisenberg]

Hola TrendyTim,

 The 'problem' that we're running into with the credit cards isn't so much whether or not it is PCI compliant to store the expiration dates,  because we know we can if we 'follow the rules' and dont store the full credit card number as well.

 Where we're kind of stuck is that we have no way to actually 'get' the expiration date to begin with when we're using an AuthNet hosted API.

 Sure, we can ask the customer for the expiration date of their cards in a separate form on our site.. but that would mean explaining to them why they have to provide that information twice (once when they fill out the actual purchase form on AuthNet's site, and again when we ask them for the expiration date on our site).

 There are two reasons we actually need the expiration date.

 1.  So we can be sure not to let a customer, who is using the CIM system for payments,  use an expired credit card.

 2.  So we can send the customer a message to let them know they need to update their payment details when a card expires, and/or warn them that a card is about to expire.

 Without the actual expiration date within our own records, or even some alternate response from AuthNet when an expired card is discovered,  there is no way to do either of those things.

 With the alternative being the additional form a customer would have to fill out to tell us the expiration dates on their CIM stored credit card,  even that has it's potential problems.

 Even if a customer did fill out a form like that, and told us that their card expires 2011-08.. then we send them a 'reminder' to update their credit card information on the CIM - we stil have no way to verify that they actually did update the information, because all we get back from AuthNet is XXXX.

 I've made the suggestion for a minor change in that.  AuthNet would still be following their own understanding of how PCI needs them to treat expiration dates, and we would all have something we could actually USE to keep customers from using expired cards.

 The answer:   If the card isn't expired,  continue to send 'XXXX' as the value of the expirationDate

 It the card is expired,  send 'EXPD'  or 'NNNN' or anything other than 'XXXX' as the value of expirationDate.

 The expiration date would still be masked..  the system would still not send the actual expiration date..  we have something we can actually use.   Seems simple enough to me :)

[Michelle]

Hey there,

Thanks for the feedback. I can verify that if you run an auth_only transaction, you will be charged and that if you don't void out an auth_only transaction or capture the funds, then you may be subject to fees from your processor.

But regardless, I'm passing on your feedback to our development teams so that they are aware of the situation and can check it out. Maybe they'll be able to come up with something!

Thanks,

Michelle

Developer Community Manager

[TrendyTim]

Sorry my bad, i misinterprited the hosted part, as im just shoehorning CIM support into our existing AIM implementation at the moment, my mind was purely from an API perspective and i have an aversion to the hosted method, i prefer add/edit card data via the api.

Arguably they could return the actual date as the PAN is not being returned, but I like your suggestion as well, it would be quite useful for those that dont store the exp date.  It would also be nice for them to implement an API to get a list of all expired cards for you as well so you could do an email blast to warn of impeding expirations, one wouldnt think it would be that hard for them to do.

Although from what i've read on the forums there are suggestions from 2 years ago that should have been a feature from the start that are still nowhere to be seen, so i wouldn't hold my breath if i were you (though i hope they will do it soon for you).

[WHeisenberg]

Maybe AuthNet just never had a suggestion made on how to help a bit with the expiration date problem that allowed them to continue to keep the date masked..  a process they insist is required by PCI standards.

My idea lets them keep right on masking the date,  but also allows the merchant to know in advance of a transaction whether a card is expired or not.   It also allows the merchant to send out a message on the 1st of every month to expired cardholders to let them know the record needs to be updated or deleted.

We'll probably not see the actual expiration date being returned..  but even XXXX = Card Expiration Valid,  NNNN = Card Expiration Passed  would be a grand step in the right direction

:)

WHeis