Credit card expiration dates in which timezone?

We know from Credit card expiration dates - Inclusive or exclusive? that credit card expires on the last day. However, in which time zone?

Solution 1:

In short, even if the current time of the transaction seems suspect, you can just run the card transaction. Let the payment network decide how it wishes to handle the case. This is as stated by Stephen Newell, here, though it isn't necessarily correct to say 'Transaction Server'.

Here's an in-depth on why, and why it is ok to let the network make the decision for you. For merchants (but not cardholders) in countries outside of the U.S. or Canada, some of the following information may not apply.

Expiration Dates and other credentials are subject to the first party in the processing chain to make a decision to reject them. When a credit card transaction is issued, it travels through the following list of parties and then back up to the consumer. If the expiration date makes it all the way down the chain to the last possible point of rejection, then the final decision is up to the issuing bank of the card. But, there are plenty of parties that may decide to reject a transaction, whether or not it is right to do so. Payment gateways or relays, where they exist, often try to preempt interchange decisions on their own.

1. Card Terminal / Point-of-Sale / Payment Application / Payment Website
   Issues Transaction.
2. One or more Payment Gateway / Payment Relays (where applicable)
   Intercepts, Relays/Forwards, or Reroutes a Transaction.
3. Processors / Settlement Clearinghouses
   Filters Transactions, Aggregates Money for the Merchant.
4. Interchange Network
   Routes Authorizations to Issuing Banks, or may Authorize for a Group of Banks
5. Issuing bank (Visa/MC) / American Express / Discover
   Issuer and Primary Authority of Card Credentials

It is worth noting that the major processors in the chain that precede the banks are all based in the United States, in the EST/EDT and CST/CDT time zones. This makes for three possible termination timezones. Any given U.S. timezone is possible, but only a handful of merchants go straight to interchange (Walmart, for example). Everyone else must go through a processor.

Parties in groups #1, #2, #4, #5 are going to be in any timezone you can imagine. For #3, there are two major Processors in the United States that handle settlement. They are First Data (FDR), and Global Payments (GPN). Both are based in the EST/EDT timezone, but most of FDR's gateways are in the CST/CDT timezone.

In order of earliest possible expiration, this gives us the following:

1. Midnight (12:00am), the first of the next month following the month and year of expiry, in GMT time.
2. Midnight (12:00am), the first of the next month following the month and year of expiry, in EST or EDT time.
3. Midnight (12:00am), the first of the next month following the month and year of expiry, in CST or CDT time.

In order of likely cutoff times, #2 and #3 are about equally likely. #1 is far less likely, as this can cause major confusion for merchants in time zones that lag behind the GMT timezone. The difference in CST/EST time is only one hour. If you want to play it safe, you should have few problems going by EST time.

As mentioned by Tony Brandner, there is also the possibility of a delayed capture of the results of a credit card transaction. By interchange rules, this can add up to 30 days for a transaction to be committed for off-line batches for non-airline merchants (Airlines and a few other businesses have really complex rules here). After 30 days, the authorization allowing a transaction will expire. But, this still requires a Merchant to start the transaction prior to card expiry.

Finally, I would find it highly suspect to accept a transaction, especially in a face-to-face customer situation, where a customer has a card labeled within a few hours of expiration. The typical lead-in time for new cards is 1 month, and most issuers try to get a new card to their clients in 2-3 months ahead of expiry. There's little excuse for a client to avoid using a new card, short of some rather unusual circumstances. Plus, you can always ask if the customer has a different card available.

Edit:

Nobody caught me on this, but I should add that the Processors should be considered the major cutoff for a number of reasons. Here are a few of interest.

1. It is often opaque to almost all parties leading up to the processors, whether a decision issued from a Processor came from someone further in the chain, or the processor itself. Thus the working assumption by people in the payment industry is that the Processor is the authority.
2. Processors have a vested interest in averting fraud, and they will flag suspect transactions and merchants if they find any. They have the power to freeze Merchant Accounts, freeze transactions, and much more. Resolving adverse reactions as a result of running a suspect transaction will almost always require consultation with the processor, since they are the gatekeepers of money transfer. They are not interested in pushing money around if it may cost them business.

Solution 2:

Came across this after doing some testing against the stripe api. It's 4:30 Pacific on Nov 30 and a 11/2015 test failed. 12/2015 worked and Stripe's API is using UTC so it explained the failure. Just in case anyone is wondering. Oh, and changing the timezone in the stripe dashboard doesn't help.

Solution 3:

Most forums seem to indicate that you should look at the timezone of the processor. However, since it can take time to process stuff (especially if you're using delayed capture), and most people get replacement cards months in advance, I'm thinking you would want to err on the side of giving yourself a buffer.

If the card expired 'Nov 2009', that translates to the end of Nov 30th, 2009. If you rejected this card starting the very end of Nov 29th, 2009, that would ensure that you're never accepting a card that has expired, regardless of timezone. Would the potential impact to customers be big?