信用卡有效期在哪个时区？
我们从信用卡到期日 - 包含还是排除？得知该信用额度卡在最后一天到期。但是，在哪个时区？
We know from Credit card expiration dates - Inclusive or exclusive? that credit card expires on the last day. However, in which time zone?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
简而言之，即使当前交易时间看起来可疑，您也可以直接运行卡交易。让支付网络决定如何处理此案。正如 Stephen Newell 在此所述，尽管“事务服务器”不一定正确。
下面深入介绍了原因，以及为什么可以让网络为您做出决定。对于美国或加拿大以外国家/地区的商户（但不包括持卡人），以下某些信息可能不适用。
到期日期和其他凭证取决于处理链中的第一方做出拒绝的决定。当信用卡交易发出时，它会经过以下各方列表，然后返回给消费者。如果到期日期使其一直到最后可能的拒绝点，则最终决定取决于该卡的发卡银行。但是，有很多方可能决定拒绝交易，无论这样做是否正确。支付网关或中继（如果存在）通常会尝试自行抢占交换决策。
发行交易。
拦截、中继/转发或重新路由事务。
过滤交易，为商家聚合资金。
将授权路由至发卡银行，或可为一组银行授权
卡凭证的发行者和主要权威机构
值得注意的是，银行之前的链条中的主要处理者都位于美国，处于 EST/EDT 和 CST/CDT 时区。这产生了三个可能的终止时区。任何给定的美国时区都是可能的，但只有少数商家直接去交换（例如沃尔玛）。其他人都必须经过处理器。
#1、#2、#4、#5 组中的派对将位于您可以想象的任何时区。对于#3，美国有两个主要处理者处理结算。它们是 First Data (FDR) 和 Global Payments (GPN)。两者都基于 EST/EDT 时区，但大多数 FDR 网关都位于 CST/CDT 时区。
按照最早可能到期的顺序，这为我们提供了以下内容：
按照可能的截止时间顺序，#2 和#3 的可能性大致相同。 #1 的可能性要小得多，因为这可能会给落后于 GMT 时区的时区的商家造成严重混乱。 CST/EST 时间仅相差一小时。如果您想安全起见，那么在美国东部时间之前应该不会遇到什么问题。
正如托尼·布兰德纳（Tony Brandner）所提到的，信用卡交易结果也有可能被延迟捕获。根据交换规则，对于非航空公司商家的离线批次提交交易可能会增加长达 30 天的时间（航空公司和其他一些企业在这里有非常复杂的规则）。 30 天后，允许交易的授权将过期。但是，这仍然要求商家在卡到期之前开始交易。
最后，我发现接受交易非常可疑，尤其是在面对面的客户情况下，客户的卡在到期后几个小时内贴有标签。新卡的典型交付时间为 1 个月，大多数发卡机构尝试在到期前 2-3 个月内向客户提供新卡。除了一些相当不寻常的情况外，客户没有什么理由避免使用新卡。另外，您可以随时询问客户是否有不同的卡可用。
编辑：
没有人注意到我这一点，但我应该补充一点，出于多种原因，处理器应被视为主要截止点。以下是一些有趣的内容。
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.
Issues Transaction.
Intercepts, Relays/Forwards, or Reroutes a Transaction.
Filters Transactions, Aggregates Money for the Merchant.
Routes Authorizations to Issuing Banks, or may Authorize for a Group of Banks
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:
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.
在对 stripe api 进行一些测试后发现了这个问题。现在是 11 月 30 日太平洋时间 4:30，11/2015 测试失败。 12/2015 有效，并且 Stripe 的 API 使用 UTC，因此它解释了失败。以防万一有人想知道。哦，更改条纹仪表板中的时区没有帮助。
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.
大多数论坛似乎表明您应该查看处理器的时区。但是，由于处理内容可能需要时间（特别是如果您使用延迟捕获），并且大多数人会提前几个月获得替换卡，因此我认为您最好宁可给自己留出缓冲时间。
如果该卡在“2009 年 11 月”过期，即到 2009 年 11 月 30 日结束。如果您从 2009 年 11 月 29 日结束时拒绝此卡，这将确保您永远不会接受已过期的卡，与时区无关。对客户的潜在影响会很大吗？
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?
我的猜测是处理交易的服务器位于何处。
My guess would be wherever the server processing the transaction is located.
其他一些商家，为了完成他们在接近到期时停止使用卡的情况：
亚马逊- 尽管他们无用的海外聊天支持，但没有与银行核实，而是通过 Javascript 锁定继续进行购买时带有有关到期的工具提示。美国东部时间之后的某个时间。在太平洋标准时间 (PST) 前 30 分钟检查。Paypal- 关于更新到期日期的 Javascript 消息，不锁定“支付”按钮，但点击后不让它执行任何操作。美国东部时间之后的某个时间。在太平洋标准时间 (PST) 前 30 分钟检查。Walmart - 页面 POST（看似异步），然后修改有关更新到期日期的消息，防止随后点击支付按钮。与付款完成时所用的时间相比，没有足够的时间与银行核实。美国东部时间之后的某个时间。在太平洋标准时间 (PST) 前 30 分钟检查。
Some other merchants, to complete the picture of when they cut off use of card close to expiry:
Amazon- Despite their useless overseas chat support, there is no checking with the bank, but a Javascript lockoff of proceeding with purchase with a tooltip about expiry. Sometime after EST. Checked 30mins before PST.Paypal- Javascript message about updating expiry date, not locking off Pay button, but not letting that do anything once clicked. Sometime after EST. Checked 30mins before PST.Walmart- POST of page (seemingly asynchronously), which then amends message about updating expiry date, preventing subsequent clicking of pay button. Not enough time to check with bank, which is in comparison to time used when the payment goes through. Sometime after EST. Checked 30mins before PST.