二度引かれた百円

新作の配信開始まで六時間。決済担当の三廻部陶子に届いたのは、たった一件の問い合わせだった。

〈百円の回復薬を買ったら、二百円引かれました〉

　試験用の購入では起きない。責任者は「利用者の勘違いでは」と言った。陶子は問い合わせの時刻とサーバーのログを並べた。同じ注文番号が、三秒差で二度記録されている。

　購入処理の途中で通信が切れると、端末はリトライする。通常なら同じ注文番号を見て二回目を断る。しかし今回、一度目は料金だけ確定し、回復薬を渡す直前で止まっていた。端末は「失敗」と判断してもう一度送り、料金が再び引かれた。

「二回目を全部拒否しましょう」

　運用責任者が言う。

「それだと、一回目で料金だけ取られた人に薬が届きません」

　陶子は決済を一つのトランザクションにまとめる修正を提案した。料金と商品を、両方成功するか両方失敗するかに揃える。ただし大きな変更を今から入れれば、別の商品まで止まる恐れがある。

　彼女はまず、同じ注文番号が来たら課金を繰り返さず、最初の結果を確認して商品だけ補う処理に切り替えた。次に通信を意図的に三か所で切った。料金確定の前、直後、商品付与の後。どの位置でも、残高と所持数が一回分だけ動くまで繰り返した。

　午前三時、修正版は通った。陶子は回線を遅くした端末でも十回購入し、残高と薬の数が必ず同時に変わることを確かめた。だが配信許可を出さず、過去一週間のログを検索した。問い合わせた一人だけではない。同じ状態になった注文が七件あった。

　返金担当を起こし、対象者へ差額を戻す一覧を渡す。責任者が「申告のない人まで？」と訊いた。

「一件見つけた時点で、七件あると分かりました。知らないまま払った人を、不具合がなかった人にはできません」

　午前五時半、七件の返金と修正の反映が終わった。配信開始の時計が進み始める。

　陶子の端末に、別の通知が出た。

〈無料配布の回復薬が、一人だけ届いていません〉

　彼女は決済画面を閉じず、今度はゼロ円の注文番号を探した。