我们从信用卡到期日知道 - 包含还是不包含?该信用卡在最后一天到期。但是,在哪个时区?
4 回答
简而言之,即使交易的当前时间看起来很可疑,您也可以运行卡交易。让支付网络决定它希望如何处理此案。正如 Stephen Newell 所说,在这里,尽管说“事务服务器”不一定正确。
以下是关于为什么以及为什么可以让网络为您做出决定的深入说明。对于美国或加拿大以外国家/地区的商家(但不是持卡人),以下某些信息可能不适用。
到期日期和其他凭证取决于处理链中的第一方做出拒绝它们的决定。发出信用卡交易时,它会经过以下各方列表,然后返回给消费者。如果到期日期一直到最后一个可能的拒绝点,那么最终决定权将取决于发卡行。但是,有很多各方可能决定拒绝交易,无论这样做是否正确。支付网关或中继(如果存在)通常会尝试自行抢占交换决策。
- 卡终端/销售点/支付应用程序/支付网站
发出交易。 - 一个或多个支付网关/支付中继 (如适用)
拦截、中继/转发或重新路由交易。 - 处理器/结算票据交换所
过滤交易,为商家汇总资金。 - 交换网络
将授权授权给发卡银行,或者可以授权给一组银行 - 发卡行 (Visa/MC) / American Express / Discover
Issuer and Primary authority of Card Credentials
值得注意的是,在银行之前的链中的主要处理器都位于美国,在 EST/EDT 和 CST/CDT 时区。这产生了三个可能的终止时区。任何给定的美国时区都是可能的,但只有少数商家直接进行交换(例如沃尔玛)。其他所有人都必须通过处理器。
#1、#2、#4、#5 组中的派对将在您可以想象的任何时区。对于#3,美国有两个主要的处理者处理结算。它们是第一数据(FDR)和全球支付(GPN)。两者都基于 EST/EDT 时区,但大多数 FDR 的网关都在 CST/CDT 时区。
为了尽可能早地到期,这为我们提供了以下信息:
- 午夜(凌晨 12:00),即 GMT 时间到期月份和年份之后的下个月的第一天。
- 午夜(凌晨 12:00),即到期月份和年份之后的下个月的第一天,在 EST 或 EDT 时间。
- 午夜(凌晨 12:00),即到期月份和年份之后的下个月的第一天,采用 CST 或 CDT 时间。
按照可能的截止时间顺序,#2 和#3 的可能性大致相同。#1 的可能性要小得多,因为这可能会给落后于 GMT 时区的时区的商家造成严重混乱。CST/EST 时间仅相差一小时。如果你想安全地玩,到 EST 时间应该不会有什么问题。
正如托尼·布兰德纳(Tony Brandner)所提到的,信用卡交易结果也有可能被延迟捕获。通过交换规则,对于非航空公司商家的离线批次提交交易最多可以增加 30 天(航空公司和其他一些企业在这里有非常复杂的规则)。30 天后,允许交易的授权将过期。但是,这仍然需要商家在卡到期之前开始交易。
最后,我发现接受交易非常可疑,尤其是在面对面的客户情况下,客户在到期后的几个小时内就有一张贴有标签的卡。新卡的典型导入时间为 1 个月,大多数发卡机构试图在到期前 2-3 个月向客户提供新卡。客户没有什么理由避免使用新卡,除非出现一些相当不寻常的情况。另外,您可以随时询问客户是否有其他可用卡。
编辑:
没有人抓住我,但我应该补充一点,由于多种原因,处理器应该被视为主要截止点。这里有一些有趣的。
- 对于处理器之前的几乎所有各方来说,它通常是不透明的,无论处理器发出的决定是来自链条中更远的人,还是处理器本身。因此,支付行业的人们的工作假设是处理器是权威。
- 处理者在避免欺诈方面拥有既得利益,如果他们发现任何可疑交易和商家,他们将予以标记。他们有权冻结商家账户、冻结交易等等。解决由于运行可疑交易而导致的不良反应几乎总是需要与处理者协商,因为他们是汇款的看门人。如果这可能会使他们失去生意,他们对推销金钱不感兴趣。
在对 stripe api 进行一些测试后遇到了这个问题。11 月 30 日太平洋时间 4:30,2015 年 11 月的测试失败。12/2015 工作,Stripe 的 API 使用 UTC,所以它解释了失败。以防万一有人想知道。哦,更改条带仪表板中的时区也无济于事。
大多数论坛似乎表明您应该查看处理器的时区。但是,由于处理内容可能需要时间(特别是如果您使用延迟捕获),并且大多数人会提前几个月获得替换卡,我认为您宁愿在给自己一个缓冲方面犯错。
如果该卡在“2009 年 11 月”到期,则意味着 2009 年 11 月 30 日结束。如果您从 2009 年 11 月 29 日开始拒绝此卡,这将确保您永远不会接受已过期的卡,无论时区如何。对客户的潜在影响会很大吗?
我的猜测是处理交易的服务器所在的位置。