オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説

オーソリ（オーソリゼーション）とは、カード会社に利用者の与信情報を照会し、その決済が通るかどうかを確認する処理です。ECサイトや決済システムを実装するうえで、オーソリと売上確定を正しく分けて設計できるかが、二重請求や在庫引当のズレといった事故を防ぐ分かれ目になります。この記事では「オーソリとは何か」という定義から一歩踏み込み、与信照会と利用枠確保という二つの機能、オーソリと売上確定を分ける二段階決済の実装、有効期限・二重オーソリ・オーソリ落ちのハンドリング、内製と受託開発のどちらで進めるかの判断軸までを、開発者が設計に落とせる粒度で整理します。

まとめ｜オーソリの仕組みと売上確定との違い・実装判断の要点

オーソリは、決済の瞬間にカード会社へ与信照会を行い、カードが有効かつ利用枠が足りるかを確認して、その金額ぶんの与信枠を仮に押さえる処理です。ここで押さえた枠は「まだ請求が確定していない仮の状態」で、実際に代金を引き落とすには売上確定（capture）という別処理が要ります。この二段階を分けて設計できると、受注時にオーソリだけを取り、出荷や役務提供のタイミングで売上確定する、といった実務に沿ったフローが組めます。

実装では、StripeならPaymentIntentのcapture_methodをmanualにすることで、オーソリ（authorization）と売上確定（capture）を明示的に分離できます。崩れやすいのは、与信枠の有効期限・二重オーソリ・オーソリ落ち（承認拒否）の三点です。有効期限はカードブランドや発行会社で異なるため確定日数を前提に組まず、期限が近い場合の再オーソリを設計に含めます。判断の分岐点は「決済フローに独自要件がどれだけあるか」で、二段階決済や分割・定期課金が絡むなら、受託開発で設計を固める価値が出ます。

オーソリ（オーソリゼーション）とは｜決済における与信照会の役割

オーソリは、クレジットカード決済の入り口で必ず走る「このカードで、この金額を、いま決済して大丈夫か」を確かめる処理です。日本語では信用照会・信用承認・販売承認・与信確保などと呼ばれ、英語のauthorizationを略してオーソリと言います。決済ボタンを押した瞬間の裏側で、加盟店・決済代行・カードブランド・発行会社の間を照会が往復し、その結果として決済の可否が返ります。

オーソリの定義と、信用照会と利用可能枠の確保という二つの中心機能

オーソリには二つの機能があります。一つはカードの有効性確認で、有効期限が切れていないか、紛失・盗難で利用停止になっていないか、不正利用の疑いがないかを発行会社が確かめる仕組みです。もう一つは利用可能枠（与信枠）の確保で、決済金額ぶんの枠をその場で押さえ、後続の別決済で枠を使い切ってしまわないようにします。この「有効性の確認」と「枠の仮押さえ」が同時に走るため、オーソリが通った時点では、代金の回収そのものはまだ確定していません。

自動オーソリと手動オーソリの違いと実務での使い分けの判断基準

オーソリには自動と手動の二種類があります。自動オーソリは、購入と同時に与信枠の確保まで完了する方式で、即時に決済を成立させたい店頭やデジタルコンテンツ販売に向く方式です。手動オーソリは、加盟店が必要なタイミングで与信を行う方式で、受注と出荷にタイムラグがある物販や、金額が後から確定する予約・従量課金で使われます。どちらを採るかは、受注から代金回収までの間に「金額や実行可否が変わりうるか」で決めると、業務の実態に沿った設計になります。

オーソリ処理のフロー｜加盟店から発行会社までの与信照会の流れ

オーソリがどこを通って可否を返すのかを押さえると、エラーが起きたときにどの層の問題かを切り分けられます。ECサイトのオーソリは、利用者・加盟店・決済代行・カードブランド（国際ブランド）・発行会社（イシュア）の五者が関わる往復で成り立ちます。

与信照会が往復する五者の役割とオーソリのリクエストの流れの全体像

典型的な流れはこうです。利用者がカード情報を入力して注文すると、加盟店（EC事業者）は決済代行を経由して与信照会のリクエストを送ります。リクエストはカードブランドのネットワークを通って発行会社に届き、発行会社がカードの有効性と利用枠を判定して可否を返す流れです。承認されれば与信枠が確保され、加盟店には承認番号（オーソリコード）が返却されます。この一連が数秒で完了するため、利用者からは一瞬に見えますが、裏側では複数の主体が同期的に応答している処理です。

オーソリで確保した与信枠と、有効期限の管理という運用上の要点

オーソリで確保した与信枠は、売上確定するまでの「仮押さえ」であり、無期限には残りません。有効期限はカードブランドや発行会社によって異なり、一般には数日から一か月程度の幅があります（2026年7月時点でも一律の日数は定義されていません）。期限を過ぎると枠は自動的に解放され、その状態で売上確定を試みると失敗します。そのため運用では、オーソリの取得日時を記録し、売上確定までに期限が迫る取引を検知して再オーソリに回す仕組みを持たせておく設計です。ここを設計に含めないと、出荷時に決済が通らない取りこぼしが発生します。

オーソリと売上確定を二段階に分ける決済の実装パターンと設計の型

決済システムを実装するうえで最も設計判断が要るのが、オーソリ（authorization）と売上確定（capture）をどう分けるかです。この二段階を理解して実装できると、受注時に枠だけ押さえ、出荷や役務提供の完了時に請求を確定する、実務に沿った決済が組めます。

authorizeとcaptureを分離する二段階決済の設計と実装の型

二段階決済は、まずオーソリで与信枠を確保（authorize）し、後から売上を確定（capture）する型です。物販なら「受注でオーソリ、出荷で売上確定」、サービスなら「予約でオーソリ、提供完了で売上確定」といった形で、代金回収のタイミングを業務に合わせられます。売上確定の際に、オーソリ金額と同額または一部の金額で確定でき、確定しなかった枠は解放される挙動です。キャンセルが入った場合は、売上確定せずにオーソリを取り消す（キャンセル・与信取消）ことで、利用者の枠を早期に戻せます。この「確定しない・一部だけ確定する・全額取り消す」の分岐を持てるのが二段階決済の実装上の利点です。

Stripeのcapture_methodで見る二段階決済の具体的な実装手順

実装イメージは、決済プラットフォームのAPIで確認すると具体化します。Stripeの場合、PaymentIntentを作成する際にcapture_methodをmanualに指定すると、決済確定時にオーソリ（authorization）だけを取り、後からcaptureを呼んで売上確定する二段階の挙動になります。既定値はautomaticで、この場合はオーソリと売上確定が一度に走る一段階決済です。取り消しはcancelで与信を解放し、部分確定はcapture時に金額を指定します。決済処理の実装パターンや手数料の考え方はStripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説で具体的に確認でき、本稿の二段階決済はその一機能として位置づけられます。

Webhookによる非同期結果の受信と冪等なイベント処理の設計

オーソリと売上確定の最終結果は、同期レスポンスだけに頼らずWebhookで受け取る設計が前提です。承認・確定・取消・拒否といったイベントを自社エンドポイントで受信し、注文ステータス更新・在庫引当・利用者への通知を非同期で処理します。実装では、受信したイベントの署名を検証して正当性を確かめ、同一イベントが再送されても二重に処理しないよう冪等（べきとう）に組むことが崩れやすい要点です。ここを疎かにすると、売上の二重計上や、確定済みなのに未反映といった食い違いが起きます。

オーソリの実装で崩れやすい論点｜二重オーソリと期限切れとオーソリ落ち

オーソリ周りの事故は、正常系ではなく例外の扱いで起きます。二重オーソリ・有効期限切れ・オーソリ落ちの三つは、実装時に必ず設計へ織り込む論点です。

二重オーソリによる与信枠の圧迫と冪等なリトライ設計上の注意点

二重オーソリは、通信タイムアウトなどで結果が不確定なままリトライし、同じ取引でオーソリを二回取ってしまう事象です。二回ぶんの与信枠が押さえられると、利用者の利用可能枠が実際の請求以上に圧迫され、後続の買い物が通らないクレームにつながります。対策は、決済リクエストに一意なキー（冪等キー）を付与し、同一キーの再送は新規のオーソリを作らず既存の結果を返す設計にすることです。タイムアウト時にすぐ再送するのではなく、まず取引の状態を照会してから再実行するフローにすると、重複を避けられます。

オーソリの有効期限切れと、再オーソリを組み込む運用設計の勘所

受注から出荷までが長い商材では、売上確定の前にオーソリの有効期限が切れることがあります。期限切れの枠で売上確定を試みると失敗するため、出荷処理の直前に有効期限までの残り日数を確認し、期限が近い取引は再オーソリを取り直してから売上確定する流れが基本です。再オーソリの時点でカードが利用停止や枠不足になっていれば、その場で検知して受注を止められるので、出荷後の未回収を防ぐ効果もあります。期限の日数を固定値で前提にせず、取得日時から動的に判定する設計にしておくのが安全です。

オーソリ落ち（承認拒否）の理由別ハンドリングと利用者への返し方

オーソリ落ちは、発行会社が与信を拒否した状態で、枠不足・カード無効・不正検知など理由はさまざまです。実装では、拒否理由のコードを受け取って、利用者に「別のカードを試す」「時間をおく」など次の行動を促すメッセージに変換する実装です。理由を伏せて一律に「エラー」とだけ返すと、本来決済できたはずの利用者を取りこぼします。一方で、不正検知による拒否の詳細をそのまま見せると不正者に手がかりを与えるため、理由の粒度は安全性とのバランスで調整する設計です。この判定は本人認証（3Dセキュア）の結果とも連動するため、認証と与信を別レイヤとして扱い、それぞれの失敗を切り分けてハンドリングします。

オーソリの実装を内製と受託開発で分ける判断軸と外注が向く局面

ここからは判断を言い切ります。オーソリの実装は、要件が単純なら内製で十分に回りますが、二段階決済や定期課金が絡むと設計品質が事故率を左右するため、体制の選び方が結果を分けます。

内製で完結できるオーソリ実装の要件と、設計上の前提となる条件

次の条件に収まるなら、内製での実装が現実的です。決済が一段階（オーソリと売上確定を同時に行う自動オーソリ）で足り、受注から回収までにタイムラグがなく、決済プラットフォームが用意する標準の決済フォームやチェックアウトをそのまま使える、というケースです。この範囲であれば、プラットフォームのSDKとWebhookの基本実装で組み切れ、与信枠の期限管理や再オーソリといった運用ロジックを自前で抱える必要がありません。まずこの標準構成で公開し、要件が複雑になってから作り込むのが工数を抑える進め方です。

受託開発で設計を固めるべき複雑な決済要件と外注が向く具体的局面

逆に、次の要件が絡むと、初期の設計品質がその後の事故率を大きく決めるため、決済設計の経験がある体制で固める価値が出ます。オーソリと売上確定を分ける二段階決済、部分確定やキャンセルを含む在庫・出荷連動、有効期限を跨ぐ長期受注の再オーソリ、定期課金やサブスクリプションの更新失敗リトライ、そして基幹システムとの受注・売上データ連携などです。これらは冪等設計・状態管理・例外ハンドリングが密に絡み、後から作り替えるとデータ不整合のリスクが高い領域になります。こうした複雑な決済・サブスクリプションの実装は決済・サブスクリプションシステムの受託開発で設計から相談でき、決済方式の選定そのものを迷う段階では決済システムとは？仕組み・種類と接続方式・自社構築の判断軸で全体像から整理できます。内製で走り出しつつ、二段階決済など難所だけ外部の設計を挟む進め方も有効です。

オーソリ（決済）でよくある質問｜仕組み・売上確定・実装の疑問

オーソリの実装検討でよく挙がる質問に、仕組み・費用・実装の観点から簡潔に答えます。

オーソリと売上確定は何が違うのですか？

オーソリは与信枠を仮に押さえる処理で、この時点では代金の回収は確定していません。売上確定（capture）は、押さえた枠に対して実際に請求を確定させる別処理です。二段階決済ではオーソリだけを先に取り、出荷や役務提供のタイミングで売上確定します。両者を同時に行う一段階決済（自動オーソリ）もあり、要件に応じて選びます。

オーソリを取っただけで料金は請求されますか？

オーソリ単体では請求は確定せず、利用者のカードには与信枠の仮押さえが立つだけです。実際の請求は売上確定を行った時点で確定します。ただし仮押さえのぶんは利用可能枠を消費するため、利用者の明細に「保留」として表示されることもある点に注意です。売上確定せずにオーソリを取り消せば、枠は解放されます。

オーソリの有効期限はどれくらいですか？

有効期限はカードブランドや発行会社によって異なり、一般には数日から一か月程度の幅があります。一律の日数は定められていないため、実装では取得日時を記録し、残り日数を動的に判定するのが安全です。期限を過ぎると枠は自動解放され、その状態で売上確定は失敗するため、期限が近い取引は再オーソリを取り直します。

二重オーソリを防ぐにはどう実装すればよいですか？

決済リクエストに一意な冪等キーを付け、同一キーの再送では新規オーソリを作らず既存結果を返す設計にします。通信タイムアウト時は即リトライせず、まず取引状態を照会してから再実行する流れが安全です。これにより、同じ注文で与信枠を二重に押さえて利用者の枠を圧迫する事故を防げます。

オーソリと3Dセキュア（本人認証）はどう違いますか？

3Dセキュアは決済者が本人かを確認する認証で、オーソリはカードの有効性と与信枠を確認する処理です。役割が異なり、一般に本人認証を通した後にオーソリが走ります。実装では認証と与信を別レイヤとして扱い、認証の失敗とオーソリ落ちを切り分けてハンドリングすると、利用者への案内を的確に出せます。

関連記事

• 決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説：オーソリを含む決済システム全体の種類・接続方式・自社構築の判断軸を整理できます。
• Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説：二段階決済（capture_method）を含む具体的な決済実装のパターンを開発視点で確認できます。
• 決済・サブスクリプションシステム開発：二段階決済や定期課金など、要件が重い決済実装を設計から相談できます。