x_exp_date - definitive formats?

[jasonjudge]

Since the DPM documentation got withdrawn and added as an appendix note to the SIM documentation, the description defining the x_exp_date field format has disappeared.

So is there a format definition of what formats are accepted for x_exp_date now?

We are finding some dates entered by users and validated by the Stripe jQuery library to the "MM/YY" format (*with* leading zeroes - I've checked) is getting a high rate of rejections. We have been told (by Auth.Net) that the date is in the "old format" but I have no idea what that means.

Any ideas?

[Joy · Accepted solution]

Hi jasonjudge,

For expiration date the accepted formats are:  MMYY, MM/YY,MM-YY, MMYYYY, MM/YYYY, MM-YYYY. I will reach out to our documentation team to add this in our SIM implementation guide.

Thanks,

Joy

[jasonjudge]

Thanks Joy,

It's good to see the documentation being kept up-to-date.

I was using the DD/YY format, with the Stripe jQuery library to do the validation and formattiing on the field. I was still getting failed cards due to a "date in an old format" or for unknown reasons. I'm not sure if users were finding a way around the formatting (e.g. with an obscure browser version) and the date was not being formatted correctly, but there was certainly an issue there. I could find ANY way to enter an invalid date - it always worked for me - but end users have this knack of being able to do the impossible.

What I have done to solve this, is to replace the single date field with two drop-downs - months and the next 15 years. The user selects the month and year, and on submit, JS validates them (must be both present and in the future) and concatenates them into a hidden "MMYY" field.

So far, that solution has worked, and the failed cards have dropped down substantially. If the user does not use JS, then the form falls back to the single x_card_exp field and the users are given the format and left to the luck of the gods to get it right. With JS present, that field gets hidden and the drop-downs are displayed.

The dropdown fields are not given names - only IDs. That way they won't get submitted and the card date will not accidentally be posted to my relay handler URL.

Hoepfully that kind of approach will be useful to others. What the original problem with the date format was (MM/YY with all leading zeroes intact), will remain a mystery I think. End users, always breaking the pretty stuff ;-)

-- Jason