クレジットカード障害（2026年10月17日）｜公式発表でわかること・7月16日との違い・二重決済の防ぎ方

まずやること：利用者は、決済エラーが出たら再試行を1回までにして別の支払い手段に切り替え、後日明細で二重計上がないか確かめます。加盟店・EC 事業者は障害の時間帯の売上データと注文を突き合わせ、1注文に2件の売上がないか確かめます。

クレジットカード障害（10月17日）でわかっていること

10/17 14時時点で確かめられた公式の告知は次の3つです。報道や SNS の利用者報告には、コンビニなどで使えなかったという声が多く出ていますが、ここでは事業者自身の告知だけを並べます。

3社の告知はどれも、どこで何が起きたかを書いていません。Zaif の「決済サービスの提供元」がどの会社かも書かれていません。原因は10/17時点で公表されていないので、本記事も原因を推測しません。

CARDNET の障害検知速報はどう読むか

CARDNET はカード決済端末を置いた店舗とカード会社のあいだで取引データを中継する会社です。加盟店向けのニュース欄に出る「障害検知速報」は、名前のとおり取引の異常を検知した時点の第1報です。

CARDNET が過去に出した速報（2019年2月の第1報など）は、次の書き方をしています。

・記載の時刻は、センターが障害を検知した時刻。利用者が障害に気づいたのはそれより前のことがある
・障害箇所や原因が分からなくても、速やかに知らせるために出す

10月17日の3本も同じ種類の知らせです。CNC と JQBC（コード支払い）のセンターにも速報が出ているので、カードだけでなく同じ経路を使うコード決済にも影響した可能性があります。ただし影響の範囲は速報の本文と続報で確かめる必要があり、速報が出たことだけでは、CARDNET が原因とは言えません。原因は後の続報や更新で出ます。2023年11月11日の CARDNET センターの障害では、告知が11月24日に更新されています。

7月16日のクレジットカード障害との違い

2026年7月16日の朝にも、全国でカード決済が通りにくくなる障害がありました。公式の記録で比べられる範囲を表にします。分からない欄は「未公表」とします。

7月16日は、決済基盤がステータスページで障害を記録し、発生箇所が早い段階で公になりました。10月17日は10/17 14時時点で、そうした記録は見つかっていません。2つの日に共通しているのは「店舗の端末でエラーが出る」「ネットの決済が失敗する」という影響の出方までで、同じ原因かどうかは公表されていません。

7月16日の Cybersource の記録が示すように、決済の障害は「完全に止まる」より先に「処理が遅れてタイムアウトする」形で出ることがあります。タイムアウトは後で説明する二重決済の入り口です。

決済エラーが出たとき利用者ができること

・再試行は1回まで。エラーが出ても、裏で承認が通っている場合がある。何度も通すと、後で二重計上として残ることがある
・別の支払い手段に切り替える。現金、別のブランドのカード。CARDNET のコード支払いセンターにも速報が出ているので、店によってはコード決済も通らないことがある
・数日後に明細を確かめる。カード会社のアプリで、同じ店・同じ金額の利用が2件ないかを見る。2件あれば、まず店に、次にカード会社に問い合わせる
・復旧はカード会社と店の告知で確かめる。SNS の「もう使える」は、店や経路が違えば当てはまらない

障害に便乗して、カード情報の入力を促す SMS やメールが届く可能性があります。障害の確認はカード会社の公式サイトかアプリで行い、メールのリンクからは開かないようにしてください。

加盟店・EC開発者の備え：タイムアウトと二重決済

EC サイトや決済を組み込んだアプリで障害時に起きやすいのが、決済は確定したのに応答が返らない状態です。決済代行のサーバーが売上を確定した後、応答を返す前にタイムアウトすると、アプリ側は「失敗」と見なして再送し、2件目の売上が確定します。利用者から見ると二重請求です。

冪等性キーには限界もあります。Stripe の説明では、キーは少なくとも24時間たつと消されることがあり、消えた後の再送は新しい請求として扱われます。同じキーで中身（金額など）が違う要求はエラーになります。決済代行がキーに対応していなければ、アプリ側でキーを送っても二重決済は防げません。その場合は照会してから再送する作りにします。

冪等性キーで二重決済を防げるか手元で試す

この仕組みを、手元の模擬 API で確かめました。一般的な仕組みの模擬で、Cybersource や CARDNET の障害を再現したものではありません。 模擬 API は初回の要求で売上を確定した後、応答を2秒遅らせます。アプリ側は1秒でタイムアウトし、1回だけ再送します。

# 決済APIの「確定後のタイムアウト」と再送を手元で模擬する（標準ライブラリだけ）
import json, sys, threading, time, urllib.request, uuid
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

DELAY = float(sys.argv[1]) if len(sys.argv) > 1 else 2.0  # 初回だけ、確定してから応答までに遅らせる秒数
charges, saved, lock, hits = [], {}, threading.Lock(), [0]

class Pay(BaseHTTPRequestHandler):
    def log_message(self, *a): pass
    def do_POST(self):
        body = json.loads(self.rfile.read(int(self.headers["Content-Length"])))
        key = self.headers.get("Idempotency-Key")
        with lock:
            hits[0] += 1; first = hits[0] == 1
            if key and key in saved:
                res = saved[key]                   # 同じキーの再送: 保存した結果を返す
            else:
                charges.append(body)               # 売上を確定する
                res = {"charge_id": f"ch_{len(charges)}"}
                if key: saved[key] = res
        if first: time.sleep(DELAY)                # 確定した後で応答が遅れる
        try:
            self.send_response(200); self.end_headers(); self.wfile.write(json.dumps(res).encode())
        except BrokenPipeError: pass

def pay(url, mode):
    order_key = str(uuid.uuid4())                  # 注文ごとに1つ作るキー
    for n in (1, 2):                               # タイムアウトしたら1回だけ再送する
        key = {"none": None, "order": order_key, "attempt": str(uuid.uuid4())}[mode]
        h = {"Content-Type": "application/json", **({"Idempotency-Key": key} if key else {})}
        req = urllib.request.Request(url, b'{"order":"A-1001","amount":1980}', h)
        try:
            return n, json.load(urllib.request.urlopen(req, timeout=1.0))
        except OSError:
            print(f"  {n}回目: タイムアウト / 決済側の売上記録 {len(charges)}件")
    return n, None

for label, mode in (("キーなし", "none"), ("注文ごとのキー", "order"), ("再送ごとに新しいキー", "attempt")):
    charges.clear(); saved.clear(); hits[0] = 0
    srv = ThreadingHTTPServer(("127.0.0.1", 0), Pay)
    threading.Thread(target=srv.serve_forever, daemon=True).start()
    n, res = pay(f"http://127.0.0.1:{srv.server_port}/charges", mode)
    time.sleep(DELAY + 0.3); srv.shutdown()
    print(f"[{label}] 遅延{DELAY}秒: {n}回目で応答 {res} / 売上記録 {len(charges)}件")

上のコードを idem_sim.py として保存し、遅延2秒（タイムアウトが起きる）と遅延0秒（起きない）で走らせます。

python3 idem_sim.py 2.0
python3 idem_sim.py 0

Python 3.13.16（Linux・x86_64）での出力です。

  1回目: タイムアウト / 決済側の売上記録 1件
[キーなし] 遅延2.0秒: 2回目で応答 {'charge_id': 'ch_2'} / 売上記録 2件
  1回目: タイムアウト / 決済側の売上記録 1件
[注文ごとのキー] 遅延2.0秒: 2回目で応答 {'charge_id': 'ch_1'} / 売上記録 1件
  1回目: タイムアウト / 決済側の売上記録 1件
[再送ごとに新しいキー] 遅延2.0秒: 2回目で応答 {'charge_id': 'ch_2'} / 売上記録 2件
[キーなし] 遅延0.0秒: 1回目で応答 {'charge_id': 'ch_1'} / 売上記録 1件
[注文ごとのキー] 遅延0.0秒: 1回目で応答 {'charge_id': 'ch_1'} / 売上記録 1件
[再送ごとに新しいキー] 遅延0.0秒: 1回目で応答 {'charge_id': 'ch_1'} / 売上記録 1件

遅延2秒では、3通りとも1回目がタイムアウトした時点で売上は1件確定していました。キーなしは再送で2件目が確定し、注文ごとのキーは保存済みの ch_1 が返って1件のままでした。再送のたびに新しいキーを作ると、キーなしと同じく2件になります。キーは注文に結びつけて作り、再送で作り直さないことが要点です。遅延0秒（陰性対照）ではタイムアウトが起きず、3通りとも1件でした。2件目の原因はタイムアウト後の再送で、アプリが同じ要求を2回送る不具合ではないことがここで分かります。各条件を3回走らせ、同じ結果でした。

この結果だけでは、自社の決済代行で二重決済が起きるかは言えません。決済代行がキーに対応しているか、キーをどれだけの期間保存するか、処理中の同じキーにどう応えるかは各社の仕様によります。確定は各社のドキュメントと、テスト環境での再現で行ってください。

参照ソース

・エポスカード「【お詫び】一部店舗でのエポスカード利用、及びNetキャッシングの不具合について」（2026-10-17）
・Zaif「【障害連絡】10/17 Zaifカード決済システムの障害のお知らせ」（2026-10-17）
・CARDNET 端末設置加盟店様 ニュース（2026-10-17 の障害検知速報3本）
・CARDNET 障害検知速報（第1報、2019年2月）
・CARDNET「11月11日 CARDNETセンターの障害について（11/24更新）」
・Cybersource Status「Authorizations and Decision Manager Service Disruption」（2026年7月）
・エポスカード「【お詫び】クレジットカード決済サービスの障害発生について」（2026-07-16）
・Zaif「【障害連絡→影響なし】7/16 Zaifカード決済システムの障害のお知らせ」
・Cybersource Developer Center「Reason Codes」（Secure Acceptance）
・Stripe API Reference「Idempotent requests」