エンジニアのための25日ルール対応 ― 再オーソリを含む決済システム設計の論点整理

2026年7月にVisa・Mastercardのオーソリ有効期限が最大25日に短縮されたことで、予約販売や受注生産を扱うECの決済システムには新しい責務が生まれました。「再オーソリのAPIを1本追加すればいい」という単純な話ではなく、期限管理・スケジューリング・失敗時のリカバリー・会計連携まで、設計すべき論点は多岐にわたります。

この記事では、自社で決済まわりのシステムを設計・保守するエンジニアやPdM向けに、25日ルール対応で発生する設計論点を整理します。特定言語のコード例ではなく、アーキテクチャレベルの意思決定ポイントに絞って解説します。

この記事で扱う「25日ルール対応」とは

本記事でいう「25日ルール対応」とは、注文から出荷までのリードタイムがオーソリ有効期限（最大25日、海外発行カードは最大7日）を超える取引において、決済の与信を出荷まで維持し続けるためのシステム設計全般を指します。単発の再オーソリAPI呼び出しではなく、期限管理・スケジューリング・リカバリー・データ連携までを含む一連の仕組みです。

ルール変更そのものの内容は「オーソリ25日ルールとは？」で、再オーソリの基本的な仕組みは「再オーソリ（再与信）とは？」で解説しています。本記事では、その対応をシステムとして実装する際に発生する設計論点に絞って扱います。

25日ルール対応で決済システムに追加される責務

25日ルール以前の決済システムは、注文時にオーソリを取得し、出荷時にキャプチャ（実売上）するという2段階の処理を持てば十分でした。オーソリの有効期間が60〜90日あったため、一般的な物販ではまず期限切れを意識する必要がなかったためです。

25日ルール施行後は、この間に「オーソリが有効期限内に収まっているかを継続的に監視し、切れそうであれば取り直す」という新しい責務が挟まります。この責務を安全に実行するには、少なくとも期限管理・スケジューリング・リカバリー・データ連携という4つの設計論点を検討する必要があります。以下、順に見ていきます。

設計論点1 ― 期限管理（注文・SKU・カード発行国ごとの期限テーブル）

最初の論点は、オーソリの残り有効期限をどの粒度で管理するかです。注文単位だけで期限を持つ設計は、一見シンプルですが実運用では不十分になりがちです。

同一注文に複数SKUが含まれ、それぞれ発送予定日が異なる分納型の予約販売では、SKUごとに期限を追う必要があります。分納・分割発送における決済設計の詳細は「分納・分割発送の予約販売決済」で扱っています。

さらに、カードの発行国によって適用される期限が異なる点も見落とせません。国内発行カードは最大25日ですが、海外発行カードは最大7日に制限されます。カード発行国（BIN情報等から判定）を注文データに保持し、期限テーブルの計算ロジックに組み込む必要があります。

設計論点2 ― 再オーソリのスケジューリングと冪等性

期限テーブルが整備できたら、次は「いつ再オーソリを発火させるか」というスケジューリングの設計です。期限ぎりぎりで発火すると、決済代行会社側の障害やレスポンス遅延に対応する余地がなくなるため、期限の数日前を起点にする設計が一般的です。

ここで重要になるのが冪等性です。再オーソリ処理はネットワーク瞬断やタイムアウトによってリトライされる可能性が高く、同じ注文に対して重複して再オーソリAPIを呼び出すと、旧オーソリの解放漏れによる二重与信や、決済代行会社側でのエラーを引き起こします。

注文IDと処理世代（何回目の再オーソリか）を組み合わせた冪等キーを発行し、同一キーでのAPI呼び出しは何度実行しても同じ結果になるよう設計する必要があります。スケジューラー自体も、複数ワーカーが同時に同じ注文を処理しないよう、分散ロックや処理中フラグの管理が求められます。

設計論点3 ― 失敗時のリカバリー（リトライ・顧客通知・出荷停止フック）

再オーソリは一定の確率で失敗します。限度額不足、カード自体の有効期限切れ、3Dセキュアの再認証要求など、原因はさまざまで、それぞれ復旧可能性が異なります。

限度額不足のように時間経過で解消しうるエラーはリトライで復旧するケースがありますが、カードの有効期限切れのように顧客の操作なしには解決できないエラーもあります。エラーコードごとにリトライ戦略を分岐させる設計が必要です。

リトライで解決しない場合は、顧客へ再決済や新しいカード情報の入力を案内する通知フローに切り替える必要があります。同時に、与信が確保できていない注文をそのまま出荷しないよう、出荷処理を一時停止するフックをOMS（受注管理システム）側に組み込んでおかなければなりません。この運用フローの設計は「オーソリ切れを防ぐ運用フロー構築ガイド」でも詳しく扱っています。

設計論点4 ― 会計・カスタマーサポートとのデータ連携

再オーソリを繰り返す設計にすると、1つの注文に対して複数のオーソリ・キャプチャの履歴が発生します。この履歴を決済システム内に閉じたまま設計すると、会計・カスタマーサポート双方で運用上の問題が発生します。

会計側では、いつ・いくらのオーソリが取得・解放・キャプチャされたかを正確に追跡できないと、売上計上のタイミング判断に支障が出ます。予約販売の会計処理の論点は「予約販売の売上計上はいつ？ IFRS15・ASC606完全ガイド」で解説しています。

カスタマーサポート側では、「なぜこの金額の保留が明細に出ているのか」という顧客からの問い合わせに答えられる必要があります。決済ログを会計・CSの両部門が参照できる形でエクスポートまたはダッシュボード化しておくことが、システム設計の一部として求められます。

見落とされがちな保守コスト ― ルール改定への追随という無限の宿題

初期実装が完了した後も、保守コストは終わりません。カードブランドのルール改定は事業者側の都合とは無関係に発生し、そのたびに期限テーブルの計算ロジックやスケジューリング条件を追随させる開発が必要になります。

実際、25日ルールの施行後も、海外発行カードの期限をさらに7日に制限する改定や、カード有効性確認目的の仮売上を禁止する規制が続けて発表されています。こうした規制の全体像は「【2026年版】Visa・Mastercard ルール変更一覧」にまとめています。ルールは今後も変わり続けることを前提に、期限計算ロジックを設定値として外出しし、変更を機動的に反映できる構造にしておく必要があります。

「作る vs 買う」を設計論点から再評価する

ここまでの4つの設計論点を並べると、「再オーソリを自社開発する」という選択が、単なるAPI連携ではなく継続的な保守体制を要するプロジェクトであることが見えてきます。比較の軸は、開発・保守コスト、カードブランドのルール改定への追随力、そして障害時のリカバリー品質に置くべきです。

Recustomer社は、こうした自動ループ処理を含む自動再オーソリ処理に関する特許（第7721200号）を取得しています。この特許は当社が長期的に技術開発へ投資してきたことの裏付けであり、期限管理・スケジューリング・リカバリーという設計論点に対する回答をすでに実装・運用してきた実績を意味します。

自社で1から設計・実装・保守するか、こうした特許技術に裏付けられたソリューションを利用するかは、社内の開発リソースとルール改定への追随体制をどこまで恒常的に確保できるかで判断するのが妥当です。詳しい比較検討は「再オーソリの自動化、自社開発か導入か」および「再オーソリを自動化する方法」でも扱っています。

よくある質問

Q. 25日ルール対応で決済システムに追加すべき機能は何ですか？

主に4つです。(1)注文・SKU・カード発行国ごとのオーソリ期限を管理する期限テーブル、(2)期限に応じて再オーソリを発火するスケジューラー、(3)失敗時のリトライ・顧客通知・出荷停止フック、(4)会計・カスタマーサポートとのデータ連携です。単発の再オーソリAPI呼び出しだけでは不十分です。

Q. 再オーソリのスケジューリングで冪等性が重要なのはなぜですか？

再オーソリ処理はネットワーク瞬断やタイムアウトでリトライされる可能性が高く、同じ注文に対して重複してAPIを呼び出すと、旧オーソリの解放漏れによる二重与信を引き起こすためです。注文IDと処理世代を組み合わせた冪等キーの設計が必要です。

Q. 再オーソリが失敗した場合、システムはどう振る舞うべきですか？

原因（限度額不足・カード有効期限切れ等）によって復旧可能性が異なるため、エラーコードに応じたリトライ戦略が必要です。加えて、解決しない場合に顧客へ再決済を案内する通知フローと、出荷処理を一時停止するフックを組み込んでおく必要があります。

Q. 決済システムと会計・カスタマーサポートの連携はなぜ必要ですか？

再オーソリの繰り返しにより、1つの注文に複数のオーソリ・キャプチャ履歴が発生するためです。会計側は売上計上タイミングの判断、CS側は顧客への保留金額の説明のために、決済ログを両部門が参照できる形にしておく必要があります。

Q. 再オーソリシステムを自社開発する場合、保守コストで見落としがちな点は何ですか？

初期実装コストだけでなく、カードブランドのルール改定が起きるたびに追随開発が必要になる点です。ルール改定は事業者側の都合とは無関係に発生するため、恒常的な保守体制を前提に設計・予算化する必要があります。

Q. 再オーソリの自動化を自社実装する場合、Recustomer社の特許との関係はどう考えればよいですか？

Recustomer社は自動再オーソリ処理に関する特許（第7721200号）を保有していますが、現時点の権利範囲は「お試し購入」（0円試着決済）に関わるものであり、予約販売の実装が一律にこれに含まれるわけではありません。特許は当社の技術的な裏付けとして提示しているものであり、比較検討の軸は開発・保守コスト、ルール改定への追随、運用品質に置くべきです。

まとめ

• 25日ルール対応は、単発の再オーソリAPI呼び出しだけでは完結しない
• 設計論点は期限管理・スケジューリング（冪等性）・失敗時のリカバリー・会計/CS連携の4つ
• 期限管理は注文単位だけでは不十分。SKU・カード発行国（海外は最大7日）まで粒度を持たせる必要がある
• 失敗時のリカバリー設計を省くと、出荷が止まる、または与信未確保のまま出荷されるリスクがある
• 保守コストの本体はカードブランドのルール改定への追随であり、初期実装後も終わらない
• 「作る vs 買う」は開発・保守コスト、ルール改定への追随、リカバリー品質を軸に判断する
• Recustomer Secureは特許（第7721200号）に裏付けられた自動再オーソリソリューションとして、これらの論点への回答を実装・運用済み

出典・参考文献

1. Visa「Visa Core Rules and Visa Product and Service Rules」（2026年7月25日発効）
2. 一般社団法人日本クレジット協会「クレジットカード不正利用被害の発生状況」
3. 特許情報プラットフォーム（J-PlatPat）「特許第7721200号」（Recustomer社・自動再オーソリ制御）

関連記事

• オーソリ25日ルールとは？
• 再オーソリ（再与信）とは？
• 再オーソリを自動化する方法 ― API・アプリ・特許ソリューションの違い
• 再オーソリの自動化、自社開発か導入か
• 分納・分割発送の予約販売決済
• オーソリ切れを防ぐ運用フロー構築ガイド
• Recustomer Secure ― 特許取得済み自動再オーソリソリューション