Clearhaus 中断历史

1. 2026年10月14日 UTC 08:55investigating

   自2026-10-14 07:15 CEST以来,我们看到Visa信贷和借记交易(Visa Direct OCT和AFT,通过/credits和/debits端点发送)的拒绝率提高,包括退还借记. 这只涉及这些交易类型,而不是签证信用卡或签证借记卡。 不幸的是,我们看到了与昨天相同的根本问题,我们不断与维萨联系,试图充分解决这一问题。 正常的签证授权,抓获,退款,和空位都不受影响,所有的Mastercard交易也一样. 我们正在与我们的上游提供者合作进行调查,并将在我们了解更多情况后公布最新情况.

2. 2026年10月14日 UTC 10:38monitoring

   12:03CEST安装了热接器,受影响服务再次正常运行. 我们正在监测局势,一旦确认问题得到解决,我们将公布最新情况.

3. 2026年10月16日 UTC 08:08resolved

   我们在2026 -10 -14 14: 09部署一个稳定固定装置 我们一直在监测并证实成功 我们仍在与Visa联系,以了解Visa方面的根本原因,但由于这一事件不再有影响,因此将考虑解决。 事发期间为07:15–12:03 CEST,86%的Visa贷方或借方收到状况代码为50000. 受影响商家将直接收到我们的通信,以澄清受影响交易的实际状况,这些交易获得状况代码为50000,并发出状况信息,表明“身份不明”.

自动翻译自官方事件更新。

1. 2026年10月13日 UTC 19:15resolved

   在协调世界时18:18至18:53之间,由于数据库中断,Merchant API无法提供结算数据。 网关交易处理在任何时候都没有受到影响。 我们为任何不便道歉.

自动翻译自官方事件更新。

1. 2026年10月13日 UTC 09:33investigating

   自2026-10-13 08:16 CEST以来,我们看到Visa信用和借记交易(Visa Direct OCT和AFT,通过/credits和/debits端点发送)的拒收率提高,包括退还借记. 这只涉及这些交易类型,而不是签证信用卡或签证借记卡。 正常的签证授权、抓获、退款和空置都不受影响,万事达卡交易也是如此。 我们正在与我们的上游提供者合作进行调查,并将在我们了解更多情况后公布最新情况.

2. 2026年10月13日 UTC 11:06monitoring

   2026-10-13 12:30起,CEST,Visa Direct OCT和AFT通过/credits和/debits端点发送,包括借方退款,一直正常运行. 我们正在监测局势,以防它复出.

3. 2026年10月13日 UTC 13:10resolved

   我们监测了局势,并确认错误率已经正常化。 这一事件现已了结.

自动翻译自官方事件更新。

1. 2026年10月9日 UTC 07:20investigating

   从2026-10-09T02:00Z开始,我们正面临断断续续的连通问题,需要我们上游供应商的授权和空白(以及Mastercard借方和借方退款)。 自动故障和回收极大地缓解了影响,但我们观察到2026-10-09T02:00Z – 2026-10-09T07:00Z之间的误差率为0.75%. 我们正在调查和联系我们的上游提供者,以便解决问题。 扣押和扣押退款以及Visa的借方和借方退款不受影响.

2. 2026年10月9日 UTC 08:26monitoring

   从06:36Z开始,我们把所有流量锁定到我们上游提供者的二级数据中心,我们看到较低的误差率为~0.04%. 07: 42Z,我们被告知,这个问题已经由我们的上游供应商解决。 从07:53Z开始,我们把流量移回了一级数据中心,没有再看到出错.

3. 2026年10月9日 UTC 09:37resolved

   我们正在结束这一事件,因为自06:36Z以来没有发现任何错误,而且问题已经确认得到解决。 2026-10-09T04:01Z至2026-10-09T06:35Z之间(第一次和最后一次出错发生时)观察到平均故障率为1.14%,出错高峰率在一分一分一秒之内. 此外,我们还观察到一小堆错误,2026-10-08T22:32Z – 2026-10-08T22:41Z,平均故障率为~11%. 对受影响的交易类型进行更正! 授权、空白、收回退款以及Mastercard信贷受到影响。 其余的交易类型(扣款、借项、借项退款和Visa贷记)没有受到影响.

自动翻译自官方事件更新。

1. 2026年9月10日 UTC 14:47resolved

   在2026-08-27T00:30:35Z和2026-08-27T00:48:01Z之间,所有Visa授权均以地位代号40400"后端问题"失败. 少数签证交易已经开始失败 2026-08-27T00:25:25Z。 主卡授权以及所有抓取、退款、空档和入分都未受影响。 自2026-08-27T00:48:01Z起,我们没有再看到连接出错. 失败的授权没有收费,可以重审。 我们正在同我们的上游提供者合作,以确定根源,并在今后防止类似的问题.

自动翻译自官方事件更新。

1. 2026年8月11日 UTC 13:24investigating

   Since 2026-08-07 00:00 CEST, we’ve seen a rise in rejections of Credit transactions by Mastercard. Credit transactions using EUR as currency are not affected. We are reaching out to our upstream provider and will post another update once we have more information. Regular authorizations and all other transaction types are unaffected.

2. 2026年8月11日 UTC 14:15identified

   We have now confirmed with our upstream provider that all non-EUR Credits are currently being rejected by Mastercard, due to a configuration change between Clearhaus, upstream provider and Mastercard. Our upstream provider are working on a rollback, and believe to be able to complete this during the night.

3. 2026年8月12日 UTC 03:32resolved

   Since 2026-08-12 00:05 CEST, approval rate of Mastercard Credits are back to normal. We are still working with the upstream provider to investigate the core issue, and ensure continued operations. Regular authorizations and all other transaction types remain unaffected.

1. 2026年8月7日 UTC 08:33resolved

   2026-08-06 UTC下午1:00至16:56之间,Google Pay的所有交易均以状态代码40000失败了"Google Pay输入错误,中间键没有有效签名". 包括Apple Pay和常规卡片交易在内的其他支付方法没有受到影响. 我们正在改进这方面的警报,以防止今后的倒退.

2. 2026年9月1日 UTC 09:42postmortem

   发生了什么事? 配置变化导致Google Pay交易失败. 修改是为了清理环境之间的配置不一致. Google Pay隐含地依赖于其中一个配置. 在移动流量到一个新的部署之前,我们总是运行自动化测试交易. 然而,Google Pay并不是自动测试,而只是根据需要测试,因为它是一种曲折的支付方法并难以自动化. 由于这一部署不包括对Google Pay的任何修改,预计不会影响它,因此没有做出额外的努力来测试Google Pay. 为什么我们发现它缓慢? Google Pay的流量比其他支付方法要少很多,所以它点击率低于我们的警戒阈值,因此我们发现这个问题的速度很慢。 预防行动 * 我们审查了类似隐含依赖关系的其余配置,没有发现任何配置。 我们改进了警示(见下文)。 +++ 改进警报 我们提高了警惕,防止影响一小部分交通的失败。 为了避免大量虚假的阳性反应, 我们做了彻底的分析和反测, 这使得我们能对每个支付方法——即使是谷歌付费等较小的支付方法——以及每个交易类型——即使是信贷等较小的支付方法发出警报。 有了这些新的警报,我们就会在最多15分钟内被通知停电.

自动翻译自官方事件更新。

1. 2026年7月6日 UTC 12:17investigating

   我们目前正在调查这一问题。 网关交易处理不受影响.

2. 2026年7月6日 UTC 12:54monitoring

   在 Merchant API 中再次可用的交易 这个问题已经得到解决。 交易现在可以在 Merchant API 中提供,服务正常运行. 网关交易处理在任何时候都没有受到影响。 我们为任何不便道歉.

3. 2026年7月6日 UTC 13:02resolved

   这一事件已经得到解决.

自动翻译自官方事件更新。

1. 2026年2月4日 UTC 12:21resolved

   The /settlements endpoint in Merchant API was unavailable and returning 500 between 2026-02-03T08:55Z - 2026-02-03T09:15Z. The incident was resolved with no lingering issues.

1. 2025年12月22日 UTC 08:55investigating

   Starting 07:48 UTC we are seeing timeouts and general connectivity issues towards both the primary and secondary data centres of our upstream provider. Authorization success rates fluctuate between ~50 % and 100 % on the primary data centre and worse on the secondary. We are in contact with our upstream provider who have confirmed that they are having a wider incident impacting several of their systems. We will update you as soon as we have more information to share, and no later than in 1 hour. Authorizations and voids are affected. Captures, capture refunds, debits and debit refunds are unaffected. Mastercard credits are affected. Visa credits are unaffected.

2. 2025年12月22日 UTC 09:45monitoring

   We saw fluctuations of success rates between 75 % and 100 % until 9:23 UTC and have seen no connectivity errors since. We continue to monitor the situation.

3. 2025年12月22日 UTC 10:57resolved

   We are closing this incident as no error has been observed since 9:23 UTC and since our upstream provider confirms that service has been restored. An average failure rate of 8.98 % was observed between 07:48:49 UTC and 09:23:30 UTC (of when the first and last error occurred). Authorizations and voids were affected. Captures, capture refunds, debits and debit refunds were unaffected. Mastercard credits were affected. Visa credits were unaffected.

1. 2025年4月25日 UTC 07:15resolved

   Starting April 11th 11:00 CEST, approximately 8% of subsequent-in-series Mastercard transactions were rejected with status code 40416 by specific issuers. For the affected issuers, a significant percentage of subsequent-in-series are rejected. No Visa transactions nor non-series Mastercard transactions were affected by this. On April 14th, the problem was noticed, and investigations have been ongoing together with Mastercard, an affected issuer, and our upstream provider. On April 17th, the problem was confirmed to be an issue with our upstream provider. On April 18th 22:00 CEST, our upstream provider released a fix. On April 19th, we confirmed that the fix was working for PAN-initiated transactions, but the problem still persisted on token-initiated subsequent-in-series Mastercard authorizations. We continued to work with our upstream provider to get this fully fixed. On April 24th 12:00 CEST, we managed to implement a workaround to mitigate the problems for token-initiated subsequent-in-series Mastercard authorizations. This fully resolved the impact of this incident. We continue to work with our upstream provider to coordinate the removal of the workaround when a fix is in place. Partners and merchants are recommended to retry both PAN- and token-initiated subsequent-in-series Mastercard authorizations that failed with 40416.

1. 2025年3月3日 UTC 09:28resolved

   On the night of 2025-03-02 we saw timeouts and connectivity issues towards our upstream provider OmniPay. Mostly we’ve been able to route traffic to a healthy data-center, but between 2025-03-02T05:27Z and 2025-03-02T05:35Z, all data-centers were not responding. The incident was resolved within 8 minutes, and we have not seen any further connectivity issues since then. We are actively working with our upstream provider to determine how similar issues can be prevented in the future when they do network updates.

1. 2024年11月20日 UTC 14:03resolved

   Between 2024-11-20T02:27:09Z and 2024-11-20T02:40:09Z we experienced connectivity issues towards our upstream provider, reaching up to 26% error rate at the peak of the incident. Only a few transactions were affected but we are posting this update for transparency. The incident was resolved within 14 minutes, and we have not seen any further connectivity issues since then.

1. 2024年10月31日 UTC 04:09investigating

   Due to a service provider we are experiencing degraded performance in the Merchant API. This does not affect our ability to process transactions.

2. 2024年11月8日 UTC 09:16resolved

   After taking remedial action, performance of the degraded components has returned to normal during the course of the week. Additionally, we have taken measures to improve visibility into the affected systems in order to strengthen our infrastructure and prevent similar events in the future. We are in contact with the service provider to continue to investigate the root cause of the issue and explore additional measures to increase the robustness of our systems.

1. 2024年10月4日 UTC 11:27resolved

   At 2024-10-03T11:26Z a warning triggered an investigation of an increase in the error rate for authorizations. The investigation showed that we were receiving a subtle amount of declines from issuers reasoned with “format error” starting 2024-10-02T05:45Z. These rejects are normal and have numerous times shown issuers to be misbehaving – which is why we have a non-zero threshold that must be met before we become aware. Together with the “format error” must be an identification of the malformatted field. This led us to identify an issue with an update we applied during 2024-10-02 resulting in AUD authorizations to be consistently declined in the time span 2024-10-02T19:55Z - 2024-10-03T17:05Z. This, however, only explained a minority of the declines. The remaining declines indicated a field that we have never populated, however, since our investigation indicated it to be an issue across multiple issuing banks, we quickly implemented a change to populate the field. Both a fix for AUD and for populating the extra field were deployed, and they turned out to fix both issues. The field population issue caused sporadic declines in the time span 2024-10-02T05:45Z - 2024-10-03T19:08Z. In summary, the two issues above caused an average 0.15 percentage point drop in approval rate in the time span 2024-10-02T05:45Z - 2024-10-03T19:08Z. We will work hard to identify how the AUD error could happen and will ensure to introduce checks to avoid a similar error to happen in the future. We will also try to work with issuers to identify the cause of the rejects based on the previously unpopulated field.

1. 2024年9月12日 UTC 04:42investigating

   Since 2024-09-12T03.39Z we have observed connectivity issues towards an upstream provider. We have reached out and are investigating with the provider.

2. 2024年9月12日 UTC 05:05investigating

   Our upstream provider has confirmed and is aware of a connectivity issue. Currently almost all authorizations, voids and Mastercard credits are impacted.

3. 2024年9月12日 UTC 06:34identified

   We have identified that the issue is with our upstream provider. We have attempted mitigating actions but unfortunately with very limited impact. We are still seeing very low approval rates that fluctuates approximately from 0 % to 15 %. Our upstream provider is trying to resolve the connectivity issue.

4. 2024年9月12日 UTC 08:41identified

   Unfortunately, we still see very high failure rates on authorizations. Our upstream provider is still trying to mitigate this critical incident. We are seeing examples where amounts are being reserved on cardholders' accounts despite the authorization failing. Therefore we recommend that subsequent-in-series recurring and unscheduled (e.g. subscriptions) are not attempted until after this incident is resolved. Furthermore, we are exploring options to potentially release these reservations.

5. 2024年9月12日 UTC 09:06identified

   We saw an improvement in approval for a short period of time from around 08:47 UTC to 08:59 UTC. Unfortunately, this has worsened again, and we are back on approval rates below 15 %.

6. 2024年9月12日 UTC 10:47identified

   We are awaiting further communication from our provider. We are actively monitoring the situation. There is no ETA for when this issue is resolved. We will update as soon as we know more.

7. 2024年9月12日 UTC 11:51identified

   We are again seeing an improvement in approval rate starting 11:46 UTC and are continuing to monitor the situation as we previously have seen such improvement temporarily.

8. 2024年9月12日 UTC 12:04monitoring

   We have seen a significant increase in approval rates and the connectivity is now back to normal. Due to the severity of this issue and the previous sudden change in approval rate we are still actively monitoring this situation.

9. 2024年9月12日 UTC 20:39resolved

   Our upstream partner has resolved their issue and our monitoring shows that the connection has been stable and without problems since our last update. We will investigate mitigating actions and the root cause of this incident and will publish a postmortem once we have a complete overview from the upstream partner. To summarize, we saw on average around 90 % of authorizations impacted during the time period 2024-09-12T03:30 - 2024-09-12T11:45 UTC. All impacted authorizations were responded with status code 50000 by our gateway API for transaction processing. We sincerely regret the inconvenience this serious incident has caused!

10. 2024年10月2日 UTC 12:35postmortem

    ## Introduction As a follow-up on the incident on 2024-09-12, this is our findings from analyzing the sequence of events. Again, we sincerely apologize for the disruption, downtime and inconvenience. ## The issue During the timespan 2024-09-12T03:30Z - 2024-09-12T11:45Z, we experienced connection failures and timeouts to an upstream provider. This affected live transactions: authorizations and voids for both Visa and Mastercard as well as credits for Mastercard. After confirming that the issue was entirely external, and that we were thus unable to mitigate it ourselves, we reached out to our provider, opened an issue with them and escalated immediately. Our automated failover moved traffic to the provider’s secondary data center when the first transactions failed towards their primary data center. While this is normally sufficient to mitigate small hiccups, this showed that the secondary data center was also affected by the incident. No transactions towards the second data center were approved and we therefore decided to only target the primary data center as we saw upwards of 10-15 % of the transactions going through there. We periodically sent small bursts of transactions to the secondary data center to monitor availability. There was a small window of 10 minutes where transactions were processed through the secondary data center before it became dysfunctional again. We contacted our provider to inform them that the secondary data center had been in a working state. After approximately 8 hours, our provider was able to mitigate the issue in both data centers, which resolved the incident, and approval rates went back to normal. For a short period of time during the incident our services were exhausted which exacerbated the condition. This resulted in the transaction gateway responding HTTP 504 Gateway Timeout which affected all transaction types. We are sincerely sorry for the inconvenience and we are working to prevent this from happening in the future. ## Remediation While we do not have any direct involvement in the incident at our provider we have learned a thing or two to take with us: 1. We will investigate the possibility to void authorizations with status code 50000 such that clients can void these transactions to ensure the state at upstream is the same representation as at the client. At the same time we will highlight that the transaction representation in the Merchant API will help in this regard to understand the state of a transaction. For critical transactions \(e.g. credits or “large enough” authorizations\) we recommend to use the [Merchant API](https://developer.clearhaus.com) to check the state of a transaction when you did not receive a response \(no matter if the failure happened on our end, somewhere in the middle, or on your end\). 2. To avoid HTTP 504 responses, we will go over our resource allocation and adjust to have a better tolerance. In addition we will improve alerting on our application load balancer to highlight when our internal systems are responding slowly and thus indicating a resource exhaustion in our system. 3. Investigate if we can improve upon the automated failover mechanism to balance traffic so we do not need to manually send small bursts to test availability. This could potentially have made us earlier aware when the secondary came up both for midways in the incident and in the very end of the incident. Already implemented improvements: 1. Extend internal dashboards to give improved visibility in the continuous success rates on the individual upstream data centers.

1. 2024年8月30日 UTC 13:34identified

   Some captures and refunds for card numbers starting with 457153 and tokens that are generated from such card numbers failed clearing this night even though Clearhaus accepted the transactions. There are two consequences for such impacted captures and refunds: 1. They do not yet appear on cardholders’ bank accounts; this is especially unfortunate for refunds. 2. They are not yet being settled on merchants’ accounts; this is especially unfortunate for captures. No action from you is required or recommended; this incident is for your information. Please notice that authorizations on both impacted cards and tokens appear to be functioning normally. Though, 3-D Secure authentications are also impacted. Transactions on any other card are not impacted! Visa has acknowledged the issue and is working with the bank that issues these cards and tokens to ensure that clearings can again go through. We await further updates from Visa and also await the issuer to resolve the problem and do expect these clearings to eventually go through. We will keep you updated whenever there is news to share. We intend to update you no later than 2024-09-03T12:00Z.

2. 2024年8月30日 UTC 19:46identified

   Visa has identified that the BINs involved in clearing failures are: 414865, 432921, 435786, 443254, 449269, 451143, 451349, 455853, 455854, 457101, 460312, 457154, 461061, 462003, 464254, 479870, 481686, 494109, 457153, and 457154.

3. 2024年9月2日 UTC 08:18resolved

   The cause of this incident was that an issuer/Visa disabled the impacted BINs although they were actively being used. Luckily, issuer/Visa succeeded in reenabling the impacted BINs over the weekend. This has propagated through systems, and made both new transactions and previously impacted transactions able to clear. After careful analysis we can confirm that all previously impacted transactions are now cleared successfully and they are also included in settlements.

1. 2024年8月2日 UTC 07:11identified

   At 2024-08-02T05:59Z we started noticing consistent failures in communication with Visa for both credit and debit transactions; neither Mastercard nor other Visa transaction types (e.g. authorizations and captures) are impacted. Visa has announced a service disruption, and we will keep you updated as we get information to share from Visa.

2. 2024年8月2日 UTC 07:27identified

   While we are awaiting an update from Visa we have to the best of our ability confirmed that transactions are not being processed upstream; thus, retrying a transaction is not expected to result in multiple processing if retried when this issue is resolved. However, we will advise you to be careful especially when retrying credit transactions.

3. 2024年8月2日 UTC 08:45monitoring

   Visa has announced that the service disruption is fully mitigated and we can positively confirm that the impacted Visa transactions are now being processed again. We will continue to monitor the error rates.

4. 2024年8月2日 UTC 09:21monitoring

   Our monitoring shows all Visa transactions are functional, and we therefore close this incident. The time window of failures lasted from 2024-08-02T05:59Z till 2024-08-02T08:13Z.

5. 2024年8月2日 UTC 09:21resolved

   This incident has been resolved.

1. 2024年4月25日 UTC 11:03investigating

   We are currently seeing an increase in declined Visa Authorizations and are currently investigating.

2. 2024年4月25日 UTC 11:52monitoring

   The issue started 2024-04-25T10:35:00Z and ended 2024-04-25T11:48:00Z when we applied a hotfix.

3. 2024年4月25日 UTC 16:51monitoring

   A significant amount of the authorizations that we responded with 50000 was approved upstream. We are currently attempting to void these approved authorizations and expect this to be completed within the next few hours. We will update this incident when the voids are completed.

4. 2024年4月25日 UTC 18:23monitoring

   All impacted authorizations have now been voided. These voids are visible via my.clearhaus.com. We expect to update and close this incident when we have tested and applied a proper solution in the coming days.

5. 2024年4月26日 UTC 11:13resolved

   The hotfix has been replaced with a proper solution that has been monitored for the last couple of hours. We are hereby closing this incident.

1. 2024年1月12日 UTC 09:57identified

   Since 2024-01-08 references have been missing on some captures, refunds and voids in the Merchant API and on my.clearhaus.com. We apologize for the inconvenience and are doing our best to quickly bring them back. Transaction processing is not affected.

2. 2024年1月15日 UTC 14:05resolved

   The missing references have been brought back. The affected captures, refunds and voids are in the time span 2024-01-08T12:33:47Z - 2024-01-13T10:16:38Z.