Webプラットフォームでの決済の種類と基礎知識

Webプラットフォームでの決済の種類と基礎知識 1

本セッションの目的 決済は見えない複雑さの塊です。開発者が実装するのはUIの一部だけ。その背後には フロー、規制、リスクが絡み合っています。 このセッションでは、決済案件を受ける前に知っておくべき基本的な考え方と、実装 時の判断ポイントをお話しします。 2

決済案件で開発者がハマる3大ポイント 1. 実装後の仕様変更 要件定義が不十分で後から大幅な設計変更 2. 想定外の失敗ケース 決済失敗時の処理設計が漏れている 3. 法規制への無理解 PCI DSSや資金移動業の規制を知らずに着手 3

最初の打ち合わせで確認する3つの要点 1. 決済フローの4ステップをどう実装するか 自動化の範囲によって工数が大きく変わる 2. カード保存やオフライン決済の有無 セキュリティ要件が著しく異なる 3. 取引構造は2社か3社か 法的責任が異なる 4

決済フローの4ステップ 1. 認証（Authorization） カードの与信枠を確保 2. 売上確定（Capture） 引き落とし確定 3. 入金（Settlement） 手数料を差し引いて事業者に振込 4. 返金対応（Refund） キャンセルと返金で対応タイミングが異なる 5

与信（Authorization）の詳細 カード情報をPSP経由でカード発行会社に送信し、利用可能性を即座に確認する。 特徴 お金は動かない（引き落としが確定していない状態） 有効期限は24時間 ~ 90日（PSPにより異なる） 有効期限内に確定されなければ自動キャンセル 与信だけするケース EC・予約販売・デポジットなど 6

Capture（売上確定）の詳細 取引を確定させ、顧客の口座から実際の引き落とし処理を実行する 特徴 ここで初めてお金が動く 与信の有効期限内に実行する必要がある Capture後は返金扱いになる（キャンセル扱いではない） 決済手数料はどこで発生する 基本的にはこのタイミング 7

オンライン決済の5つの実装パターン 8

オンライン決済の5つの実装パターン シナリオ 難易度 使用場面 都度入力 低 単発購入 カード保存 中 リピート購入 バックグラウンド 高 自動精算・定期 予約注文 中 将来決済 サブスク 高 定期課金 9

パターン1：都度入力型 ECサイトの基本形態 ユーザーが購入のたびにカード情報を入力 実装は比較的シンプル 入力の手間からコンバージョン率が下がる可能性 適用例 一般的なECサイト 低頻度の購入 10

パターン2：カード保存型 ワンクリック決済 初回にカード情報を登録 2回目以降はワンクリックで決済 トークン化が必須（カード情報を直接保存しない） 適用例 リピート購入が多いEC フードデリバリー タクシー配車アプリ 11

パターン3：バックグラウンド決済 ユーザー操作なしで自動課金 従量課金や追加課金 失敗処理の設計が特に重要 通知とリトライのロジックが複雑 適用例 クラウドサービスの利用料金 ゲームのアイテム課金 従量制の課金システム 12

パターン4：予約・事前承認型 予約時はオーソリのみ、利用後にキャプチャ オーソリゼーションの有効期限（通常7日程度）に注意 キャンセル処理の実装が必要 オーソリ期限切れの再オーソリ対応 適用例 ホテル予約 レンタカー イベントチケット 13

パターン5：サブスクリプション型 定期的に決済を実行 初回決済と継続決済で処理が異なる プラン変更時の日割り計算 解約時の返金処理 失敗時の再試行とサービス停止の判断 適用例 動画配信サービス SaaS製品 オンラインサロン 14

バックグラウンド決済の失敗処理設計 15

再請求ロジックの設計 リトライの回数と間隔 即座に再試行 or 数時間後 or 翌日？ 失敗の種類を判別する 一時的な失敗：限度額超過、ネットワークエラー 恒久的な失敗：有効期限切れ、カード停止 カード情報の更新タイミング 有効期限が近づいているカードへの事前通知 16

未回収時の対応フロー 通知方法 メール / アプリ内通知 / SMS どのタイミングで、どの手段を使うか サービス停止の判断 何回失敗したら停止するか 段階的な機能制限 or 即座の完全停止 社内エスカレーション カスタマーサポートへの通知 手動督促の判断基準 17

自動化と人的対応の境界線 すべて自動化 コストは下がる 顧客との関係悪化リスク すべて人手で対応 丁寧な対応が可能 人件費が膨らむ 取引額や顧客層に応じた設計が重要 高額取引は人が介入 少額取引は自動化 18

プラットフォームビジネスの決済設計 19

資金移動業の規制 他人のために資金を移動させる行為は規制対象 顧客から受け取った代金をプラットフォーム側で預かり、後日出店者に送金 → 資金移動業に該当する可能性 資金移動業の登録は厳格な要件 スタートアップや中小企業が独自取得するのは非現実的 自前実装は避けるべき 20

マネーロンダリング対策 犯罪収益移転防止法への対応 本人確認（KYC）の実施 取引モニタリング 疑わしい取引の報告義務 不正な資金の流れを防ぐための厳格な管理が必要 21

PSPのプラットフォーム向け機能の活用 現実的な解決策 Stripe Connect その他PSPのマーケットプレイス機能 メリット PSP側で資金を管理（資金移動業のライセンス保有） プラットフォーム事業者は決済フローの制御のみ 規制対応の負担を大幅に軽減 22

エスクロー期間と入金サイクル 資金保持期間の設計 顧客からの入金から出店者への送金までの期間 返品やクレームに備えた資金保持 プラットフォームの信頼性とキャッシュフロー管理のバランス 入金サイクルの設定 週次 / 月2回 / 月1回 出店者の事業規模に応じた柔軟な設定 23

知っておくべき法規制 24

特定商取引法 表示義務のある情報 事業者名、住所、電話番号、代表者名 販売価格、送料 支払方法、引渡時期 返品特約 特に注意：定期購入・サブスクリプション 解約方法の明示 契約期間の明示 25

改正割賦販売法 クレジットカード情報の非保持化 原則として事業者はカード情報を保持してはならない PSP側にカード情報を管理してもらう実装が推奨 もし自社で扱う場合 PCI DSS（国際的なセキュリティ基準）への準拠が必要 極めて高いハードル 26

クレジットカード・セキュリティガイドライン 実行計画のセキュリティ要件 不正検知システムの導入 本人認証（3Dセキュア）の実装 セキュリティコード認証 取引モニタリング 参照 クレジット取引セキュリティ対策協議会 チェックリスト形式で具体的な要件を確認可能 27

法規制は定期的に改正される 最新情報の確認が必須 経済産業省のウェブサイト 一般社団法人日本クレジット協会 各PSPの提供する情報 実装前に必ず最新の規制を確認する 28

もう一つの注意点 29

生成AIが生成するコードを信じすぎない
1. 現在の日本では機能しないコード

// 3DSの処理が完了できない
const {token} = await stripe.createToken(cardElement);
const charge = await stripe.charges.create({
amount: 3000,
currency: 'jpy',
source: token.id
});

30

適切な情報ソースを参照させる Stripe Docs AI Stripe Docs Markdown Stripe MCP ( Documentation tool ) 31

まとめ 32

決済実装に必要な包括的な視点 1. 技術的な実装だけでなく 2. ビジネス要件の確認 3. PSPの選定 4. 失敗時の運用設計 5. 法規制への対応 すべてが重要 33

実装してリリースすれば終わりではない 継続的なメンテナンスが必要 運用開始後の失敗処理 顧客対応 法改正への追従 セキュリティアップデート 特にバックグラウンド決済やプラットフォーム型では、事前設計が不十分だと大きな 手戻りが発生する 34

最初の打ち合わせで確認する3つの要点 1. 決済フローの4ステップをどう実装するか 与信や返金周りは考慮漏れしやすいので注意 2. カード保存やオフライン決済の有無 5つの決済シナリオのどれを選ぶかを確認する 3. 取引構造は2社か3社か 「プラットフォーム」に注意 35

まとめ 決済は見えない複雑さの象徴。 シンプルなUI背後には、フロー・規制・リスクが絡み合っています。 事前の十分な協議が、堅牢で持続可能なシステム構築につながります。 36

37