---
title: "売上確定（キャプチャ）とは？オーソリとの違いと決済システム実装の勘所【2026年版】"
url: "https://www.issoh.co.jp/tech/details/15738/"
published: 2026-07-27
updated: 2026-07-27
categories: ["開発"]
publisher: "株式会社一創"
---

# 売上確定（キャプチャ）とは？オーソリとの違いと決済システム実装の勘所【2026年版】

売上確定（キャプチャ）は、クレジットカード決済でオーソリによって確保した与信枠に対し、実際の請求をかけて売上を成立させる決済処理です。カード決済は「与信を取る」処理と「請求を確定する」処理が分かれており、この後半にあたるのが売上確定にあたります。この記事では、オーソリ（与信）との役割分担、二段階決済（Auth/Capture）と即時売上の違い、Stripe・PAY.JP・Squareのcapture API、部分確定や与信失効、二重請求を防ぐ設計まで、決済システムを実装する立場で解説します。EC・サブスク・予約販売など、請求タイミングを商品の出荷や役務提供に合わせたい開発者向けの内容です。

## まとめ｜売上確定は与信と請求を分けて確定タイミングを制御する処理

売上確定とは、オーソリ（authorization）で確保済みの与信枠に実請求をかけ、加盟店の売上として成立させる処理です。カード会社から利用者に代金が請求されるのは、この売上確定が行われた時点になります。オーソリと売上確定を分離すると、注文時に与信だけ押さえ、出荷や役務提供の完了を待って請求を確定できます。

実装上の要点は3つに絞れます。第一に、与信枠には有効期限があり、期限を過ぎた枠は失効して確定できなくなるため、確定処理は期限内に走らせる設計が要ります。第二に、確定金額はオーソリ金額を上限とし、多くの決済サービスは超過確定を認めません（減額の部分確定は可）。第三に、確定処理はべき等キーと決済Webhookで二重実行と取りこぼしを塞ぎます。予約販売や受注生産では確定を遅らせる設計が有効ですが、失効リスクと引き換えになる点を判断軸として本文で言い切ります。

## 売上確定（キャプチャ）とは何か｜与信確保と実請求を分ける決済処理

クレジットカード決済は、単に「支払う」1回の処理ではありません。カード会社に利用可否を照会して枠を押さえる処理と、その枠に請求を確定する処理の2段構えになっています。売上確定は後者を指し、英語では capture、国内の決済実務では「実売上」「売上処理」とも呼ばれます。

### 売上確定（実売上）の定義とオーソリ（与信枠確保）との役割分担

オーソリ（オーソリゼーション）は、カードが有効か、利用枠が足りるかをカード会社へ照会し、承認を得て与信枠を確保する処理です。この段階では利用者に請求は発生せず、枠が仮に押さえられた「仮売上」の状態にとどまります。売上確定は、その仮売上を「実売上」へ転じ、請求を成立させる処理です。与信取得の詳細は[オーソリ（決済）とは何かを解説した記事](https://www.issoh.co.jp/tech/details/15420/)で扱っており、本記事はその次工程である確定処理に絞ります。押さえた枠の性質は[与信枠の仕組みを整理した記事](https://www.issoh.co.jp/tech/details/15736/)もあわせて確認してください。

### 二段階決済（Auth/Capture）と即時売上（同時決済）の処理フロー

売上確定の設計は、大きく2方式に分かれます。オーソリと確定を別タイミングで行う「二段階決済（Auth/Capture）」と、決済リクエスト1回で与信取得と確定を同時に済ませる「即時売上（同時売上・オーソリ&キャプチャ）」です。物販ECは出荷まで確定を待つ二段階が向き、デジタルコンテンツの即時提供や少額課金は即時売上が向きます。処理の流れを並べると次のようになります。

| 方式                  | 与信取得         | 売上確定             | 向くケース              |
| ------------------- | ------------ | ---------------- | ------------------ |
| 二段階決済（Auth/Capture） | 注文時にオーソリのみ   | 出荷・提供完了時にcapture | 物販EC・予約販売・受注生産     |
| 即時売上（同時決済）          | 決済リクエストで同時取得 | 同一リクエストで即確定      | ダウンロード販売・即時提供の少額課金 |

二段階にすると、在庫欠品やキャンセルが確定前なら請求を起こさずに済みます。確定前の取り消しは与信の解放（オーソリキャンセル）で完結し、返金処理より簡潔です。

### 仮売上・実売上・与信枠という決済用語の対応関係とステータス設計

用語の対応を押さえておくと実装の会話が噛み合います。「仮売上」はオーソリ済みで確定前の状態、「実売上」は売上確定後の状態、「与信枠」はオーソリで押さえたカードの利用可能額の一部です。売上確定は仮売上から実売上へ状態遷移させる操作であり、状態遷移として決済レコードのステータス管理に落とし込むと、後述の二重請求対策が実装しやすくなります。

## 売上確定APIの実装パターン｜主要決済サービスのcapture処理

売上確定は、決済代行サービスのAPIを通じて実行します。方式名や引数はサービスごとに異なりますが、「オーソリ時に確定を保留し、後から確定APIを叩く」という骨格は共通です。ここでは主要3サービスの型を並べ、実装の勘所を示します。

### Stripe・PAY.JP・Squareの売上確定API呼び出しの型

各サービスとも、決済作成時に「即時確定するか、確定を保留するか」を指定し、保留した場合は別途確定APIを呼びます。呼び出しの対応は次のとおりです。

| サービス                   | 確定保留の指定                     | 売上確定の操作                  |
| ---------------------- | --------------------------- | ------------------------ |
| Stripe（PaymentIntents） | `capture_method: manual`    | PaymentIntent を capture  |
| PAY.JP（Charge）         | `capture: false` で支払い作成     | 該当 charge の確定APIを呼ぶ      |
| Square（Payments）       | `autocomplete: false`（遅延確定） | 該当 payment を complete する |

実装例としてStripeを使う場合の詳細は[Stripeの仕組みと実装を解説した記事](https://www.issoh.co.jp/tech/details/15416/)を参照してください。いずれのサービスでもAPIの版は更新されるため、確定エンドポイントの引数名や挙動は各公式ドキュメントの最新版で実測し、本番実装前にサンドボックスで確定フローを一度通しておきます。

### 部分売上確定（一部キャプチャ）と複数回に分けた確定処理の可否

売上確定は、オーソリ金額の全額を確定するとは限りません。確定額をオーソリ金額より小さくする「部分売上確定（一部確定）」に対応するサービスが多く、複数商品の分割出荷や一部キャンセルに使えます。ただし挙動には差があります。

- 確定額はオーソリ金額が上限。超過確定は原則不可で、増額したい場合は再オーソリが要る
- 1件のオーソリに対する確定回数は「1回のみ」のサービスと「複数回の部分確定可」のサービスがある
- 部分確定すると、残りの与信枠は自動解放されるか、明示的な解放が要るかがサービスで分かれる

分割出荷を扱うなら、部分確定の回数制限を先に確認し、制限がある場合は「出荷単位でオーソリを分ける」設計に切り替えます。

### 与信枠の有効期限と自動失効を見込んだ再オーソリと確定処理の設計

オーソリで押さえた与信枠には有効期限があり、期限を過ぎると枠が失効して売上確定ができなくなります。期限は各カードブランド・アクワイアラの規約で定まり、一般に数十日程度ですが、決済サービスや契約で異なるため、自社の契約条件を一次情報で確認します。予約販売などで確定が期限を超えそうな場合は、期限が近づいた時点で再オーソリをかけて枠を取り直す設計が有効です。失効を検知せず確定APIを叩くと確定エラーになるため、期限をレコードに保持し、確定バッチで期限判定を挟むのが実装の定石です。

## 売上確定で失敗しやすい実装の落とし穴｜二重請求と与信失効を防ぐ設計

売上確定は請求を成立させる操作のため、実装の誤りが二重請求という金銭事故に直結します。ここでは開発で踏みやすい落とし穴と、その塞ぎ方を挙げます。

### べき等キーと決済Webhookで防ぐ売上確定の二重実行の対策

確定APIの呼び出しがタイムアウトし、レスポンスを取りこぼしたまま再送すると、同じ与信枠に二重で確定をかける恐れがあります。これを防ぐ基本は2つです。ひとつはべき等キー（idempotency key）を確定リクエストに付け、再送しても同一処理として扱わせること。もうひとつは確定結果を決済サービス側の通知で受け取り、自社の状態を同期させることです。確定完了やエラーの非同期通知は[決済Webhookの設計を解説した記事](https://www.issoh.co.jp/tech/details/15734/)で扱う仕組みで受け、Webhookの再送に備えて受信側もべき等に作ります。

### 予約販売・受注生産で売上確定を遅らせる設計の判断基準と失効リスク

予約販売や受注生産では、商品を用意できてから確定したいという要件が生じます。二段階決済で確定を遅らせれば実現できますが、遅らせるほど与信失効のリスクが上がります。判断軸は「提供までのリードタイムが与信有効期限に収まるか」です。収まるなら二段階決済で出荷時に確定し、収まらない長期の予約なら、確定を遅らせるのではなく、期限前の再オーソリを組むか、あるいはサブスクのように[継続課金の仕組み](https://www.issoh.co.jp/tech/details/15728/)へ寄せて分割請求に切り替える判断が要ります。ここを曖昧にすると、期限切れで確定できず売上を取りこぼします。

## 売上確定の状態管理は内製で組むべきか外注に委ねるべきかの判断基準

売上確定の実装そのものは、決済代行サービスのAPIを叩くだけに見えます。しかし本番運用に耐える売上確定には、失効・部分確定・二重請求・Webhook再送・返金との整合まで含めた状態管理が要り、ここで難度が上がります。内製と外注の線引きを条件付きで整理しました。

即時売上のみで、部分確定も遅延確定も要らない単純な物販なら、決済サービスの標準SDKで内製して差し支えありません。一方、二段階決済で出荷連動の確定・分割出荷の部分確定・与信失効時の再オーソリ・返金や一部返金まで扱うなら、決済状態機械の設計と経理照合の要件が絡み、内製だけで組むと二重請求や計上ずれの温床になりがちです。この領域は決済実装の経験が効くため、自社に決済システムの構築知見が薄いなら、要件定義から設計を外部に委ねるほうが事故を避けられます。一創では[決済・サブスクリプションシステム開発](https://www.issoh.co.jp/service/system/payment/)として、Auth/Captureの状態管理や照合まで含めた実装を請けています。全体像は[決済システムとは何かを整理した記事](https://www.issoh.co.jp/column/details/15263/)もあわせて参照してください。

## よくある質問

売上確定について、決済システムの実装でよく問われる点を5つ挙げます。

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

オーソリはカードの利用可否を照会して与信枠を確保する処理で、この段階では請求は発生しません。売上確定は、確保済みの枠に実際の請求をかけて売上を成立させる処理です。オーソリが「枠の確保」、売上確定が「請求の確定」と役割が分かれています。

### 売上確定をしないとどうなりますか？

オーソリだけで確定しないと、加盟店に売上は立たず、利用者への請求も起きません。押さえた与信枠は有効期限を過ぎると失効し、枠が解放されます。確定漏れは売上の取りこぼしになるため、確定バッチで未確定レコードを監視します。

### 売上確定の後でキャンセルや返金はできますか？

確定前ならオーソリのキャンセル（与信解放）で請求を起こさず取り消せます。確定後は返金（リファンド）処理で、全額返金と一部返金の2種類です。確定前の取り消しと確定後の返金は別のAPI・別の会計処理になるため、状態で分岐させます。

### 部分的に売上確定することはできますか？

多くの決済サービスがオーソリ金額以下での部分確定に対応しており、分割出荷や一部キャンセルに使えます。ただし確定回数の上限やオーバー確定の可否はサービスで異なるため、分割出荷を扱う場合は事前に仕様を確認します。

### 与信枠の有効期限が切れると売上確定できませんか？

失効した与信枠には確定をかけられず、確定APIはエラーになります。提供まで期限を超えそうな予約販売では、期限前の再オーソリで枠を取り直すか、継続課金への切り替えが選択肢です。期限はレコードに保持して確定処理で判定します。

## 関連記事

- [オーソリ（決済）とは](https://www.issoh.co.jp/tech/details/15420/)：売上確定の前工程にあたる与信取得の仕組みを実装視点で解説
- [与信枠とは](https://www.issoh.co.jp/tech/details/15736/)：オーソリで押さえる与信枠の性質と有効期限を整理
- [決済Webhookとは](https://www.issoh.co.jp/tech/details/15734/)：売上確定の完了・失敗を非同期で受け取る通知設計
- [Stripeとは](https://www.issoh.co.jp/tech/details/15416/)：PaymentIntentsでのAuth/Capture実装の具体例
- [サブスクリプション課金とは](https://www.issoh.co.jp/tech/details/15728/)：継続課金で確定を分割請求へ寄せる場合の仕組み
- [決済システムとは](https://www.issoh.co.jp/column/details/15263/)：決済システム全体の構成と売上確定の位置づけ

---

出典: [売上確定（キャプチャ）とは？オーソリとの違いと決済システム実装の勘所【2026年版】](<https://www.issoh.co.jp/tech/details/15738/>)（株式会社一創）
