1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 2

決済を実装した体験談や決済関連（クレカ、QRコード、何でもOK！）の情報を投稿しよう！ by PAY Advent Calendar 2025

@Seine_A_Shintani(新谷 正嶺)Team Coffeein中部大学 新谷研究室 / Shintani Lab, Chubu University

決済実装は「技術」より先に「設計」と「責任」が来る —— 社会人がオンライン決済を導入するときの意思決定とチェックリスト（PAY.JPを例に）

1
Last updated at Posted at 2025-12-15

この記事は PAY Advent Calendar 2025 の投稿です。
私は私大の大学教員で、決済実装の経験はありません。その立場から「決済を入れる必要が出てくる典型シーン」「手段の比較」「実装・運用で落とし穴になりやすい点（税務・法務を含む）」を調べた一次情報を軸に整理します。
※本記事は一般的な情報提供であり、法的助言・税務助言ではありません。個別案件は所属組織（大学・会社）の規程や、税理士・弁護士等の専門家にご相談ください。

TL;DR（先に結論）

  • 「決済を実装する」と言っても、実際は (A) 既存プラットフォームを使う / (B) 決済APIを組み込む / (C) 決済そのものを作る の3層がある。多くの社会人は (A) か (B) で十分。
  • 実装上の最重要原則は 「カード番号を自分のサーバに送らない」。トークン化（Checkout / payjp.js / SDK など）を前提に設計する。
  • Webhook / べき等性 / 失敗時の再実行 を先に設計しないと、運用で破綻する（「購入完了画面で全部やる」問題）。
  • 法務・税務の落とし穴は、だいたい 「表示義務（特商法）」「取消/返品」「消費税（免税点・インボイス）」「前払式支払手段（資金決済法）」 に集約される。

想定読者

  • 社会人（会社員、大学教員、個人事業、副業、家事育児中の方など）で
    「小さく有料サービスを始めたいが、決済は怖い」
    「どこまで自分で作るべきか分からない」
    「税金や法規制が気になる」
    という方
  • あるいは、チーム内で「決済の責任範囲」を整理したいエンジニア／PM

1. 社会人が「決済の仕組み」を必要とする典型シーン（職種別）

決済はECの専売特許ではありません。社会人が「お金を受け取る仕組み」を必要とする局面は、かなり多様です。

会社員（兼業・新規事業・業務で）

  • 小規模SaaSのサブスク（月額課金）
  • 研修・コンサル・メンタリングの単発チケット販売
  • 社内の有料イベント（外部向け）の参加費回収
  • 法人向け請求（請求書払い）と個人向けカード払いの併存

大学教員（研究・教育の周辺で）

  • 有料の公開講座・ワークショップ・オンライン講義
  • 研究室主催イベントの参加費（学外の一般参加を含む）
  • 学会・研究会の参加費回収（※多くは学会側の仕組みがあるが、立ち上げ期に必要になることがある）
  • 研究室制作物（冊子、教材、ツール等）の頒布
    ※ここは所属機関の会計規程・利益相反（COI）・兼業規程が絡むことが多く、「技術」以前に「手続き」が重要です。

専業主婦/主夫・個人（生活に寄り添う形で）

  • ハンドメイド、講座、デジタルコンテンツ販売
  • 子ども向け教室、地域活動の参加費
  • 「予約→支払い→当日提供」のシンプルな流れをオンライン化したい

2. 「決済を実装する」の3層（ここを混同すると事故る）

決済は、どこまでを自分が責任を持つかで難易度が激変します。

  • (A) 決済を“実装しない”：プラットフォーム（ECカート/マーケット/チケット販売/決済リンク等）で完結
    → 最短。責任も委ねられるが、自由度は低い。
  • (B) 決済APIを“組み込む”：決済代行（PSP）のAPIを使い、自分のサービス体験に統合
    → 体験設計の自由度が上がる。責任範囲が増える。
  • (C) 決済そのものを“作る”：カード情報の保持、決済ネットワーク接続、加盟店契約など
    → ほとんどの個人・小規模チームには非現実的（安全・監査・法務・運用が重い）。

本記事の主戦場は (A) と (B) です。(C) は「やらない判断」をするために触れます。

3. 手段の比較（社会人が取り得る現実的オプション）

「何を売りたいか」「誰に売りたいか」「継続課金か」「どれだけカスタマイズしたいか」で最適解は変わります。
まずは選択肢をテーブルで俯瞰します（例なので、具体サービス名はご自身の状況に合わせて読み替えてください）。

手段 導入スピード カスタマイズ 運用/責任 典型用途 つまずきポイント
銀行振込・請求書 速い 低い 中（入金消込が大変） B2B、少数高単価 入金照合、誤入金、督促、海外対応
決済リンク/請求リンク 速い 低〜中 低〜中 単発の講座、寄付 購入後の自動化（台帳/メール）
EC/チケット/講座プラットフォーム 最速 低〜中 低 物販、イベント 仕様制約、手数料、顧客データの扱い
決済API（PSP）組み込み 中 高い 高（ただしカード情報は非保持化可能） SaaS、会員、独自フロー Webhook/再送/返金、特商法表示、税務
前払残高/ポイントを自前で発行 遅い 高い 最高 アプリ内通貨 資金決済法（前払式支払手段）など法規制

4. まず押さえる：決済は「状態遷移」を設計する仕事

決済実装で一番よく見る事故は、「購入完了画面に全部押し込む」ことです。
ネットワークは落ちます。カード認証は遅延します。Webhookは重複します。返金も起きます。

だから最初に必要なのは「画面」ではなく 状態遷移（State Machine） です。

例：単発購入（最小構成）

  • CREATED：注文作成（在庫確保はここでやる/やらないを決める）
  • PAYMENT_PENDING：決済開始（3Dセキュア等で時間がかかる可能性）
  • PAID：支払い成功（Webhook等で確定）
  • FULFILLED：提供完了（デジタル納品/発送/受講権付与）
  • CANCELED：キャンセル
  • REFUNDED：返金済み

決済は「お金の確定」と「提供の確定」を分けるのが基本です。
これができると、タイムアウトや二重送信が来ても壊れにくい。

5. 最小アーキテクチャ（「カード番号を自分のサーバに送らない」を実現する）

Qiitaの決済記事で100回言われているやつですが、それでも事故が起きるので、ここでも言います。

カード情報は、あなたのサーバを経由させない。
代わりに、決済サービス側でトークン化して「使い捨てのトークン」だけを自サーバに送る。

図：典型フロー（トークン化 + サーバ側課金 + Webhook）

6. セキュリティと不正対策：最低限ここまでは“仕様”にする

6.1 EMV 3-Dセキュア（3Dセキュア2.0）を前提にする

日本では、クレジットカード不正利用対策のガイドラインで 原則として全EC加盟店がEMV 3-Dセキュア導入を求める方針が示されています（期限は2025年3月末）。
2025年末時点では「対応していて当然」の前提で設計するのが安全です。

  • 3Dセキュアが入ると、支払いは“即時に確定しない”場合がある
    → だからこそWebhook/状態遷移が必須

6.2 PCI DSS / 非保持化：カード情報に触れない設計へ

カード番号・CVCを自前で受け取ると、監査・運用の重さが段違いになります。
多くのPSPは、カード情報をトークン化する仕組み（フォーム/SDK）を提供しています。

（例）PAY.JPでは payjp.js が「カード情報入力フォーム生成 + トークン化」を提供しています。

6.3 Webhookの“正当性”確認

Webhookは公開URLに飛んでくるので、「本当に決済サービスから来たのか」を検証しないといけません。
PAY.JPの場合は、Webhookヘッダーに X-Payjp-Webhook-Token が含まれるので、これを照合します（公式ドキュメントに明記）。

# 例: Flask での超シンプルな正当性チェック
import os
from flask import Flask, request, abort

app = Flask(__name__)
EXPECTED = os.environ["PAYJP_WEBHOOK_TOKEN"]

@app.post("/webhook")
def webhook():
    token = request.headers.get("X-Payjp-Webhook-Token")
    if token != EXPECTED:
        abort(401)

    event = request.get_json()
    # TODO: event["id"] を記録して重複排除（べき等）
    return "", 200

6.4 べき等性（idempotency）＝二重課金・二重提供を防ぐ最後の砦

Webhookは重複することがあります。API呼び出しも再送されます。
対策はシンプルで、イベントIDや注文IDで「一度処理したか」を判定します。

7. 運用で死なないためのチェックリスト（現場で効くやつ）

7.1 決済に「例外系」が多い理由（技術ではなく現実）

  • カード会社側でのリスク判定（3Dセキュア含む）
  • 回線・端末依存（モバイル、地下鉄、海外）
  • タイムアウト/二重送信（ユーザーの連打も含む）
  • キャンセル・返金・チャージバック

7.2 最初から仕様に入れておく項目

  • 決済成功/失敗/認証中 のUI（ユーザーに「待つ」ことを説明できるか）
  • 返金（全額/一部）と台帳処理
  • 入金消込（売上計上と入金日がズレる）
  • 請求書・領収書（誰が、いつ、どの形式で出すか）
  • 監査ログ（誰が返金したか、管理画面操作ログ）
  • 問い合わせ導線（「課金されたのに届かない」へ対応できるか）

8. 法務・税務：実装より先に“決めておく”べき論点

ここは「技術」ではなく「責任」の話です。
私は専門家ではないので、一次情報（官公庁・法令）に当たりながら、実装者が踏みやすい地雷を整理します。

8.1 特定商取引法（通信販売）：表示義務

ネットで商品やサービスを販売する場合、広告に表示すべき事項があります。
典型的には、価格、送料、支払時期・方法、提供時期、返品・解約、事業者情報など。

また、近年は「最終確認画面（注文確定直前）」での表示や、誤認を招く表示の禁止なども整理されています。
決済画面を作る前に、「表示すべき事項」を文章として用意しておくのが現実的です（UIに埋め込むため）。

実装Tips：

  • 決済フォームだけ綺麗でも、表示義務が抜けると行政対応・返金対応に発展し得る
  • 「定期購入」「総額」「解約条件」は特に揉めやすい（UIで明示する）

8.2 消費税：免税点とインボイス（適格請求書）

  • 「売上が一定規模を超えると消費税の納税義務が生じる」
  • インボイス（適格請求書）を発行するには登録が必要
  • そして インボイス発行事業者として登録すると、売上規模が小さくても免税にならない場合がある（要注意）

実装Tips：

  • 売上はPSP管理画面で見られても、確定申告/会計は別物（手数料や返金の扱いを整理する）
  • 「B2Bで請求書が必要」と言われると、インボイスが論点になりやすい
  • “決済導入”は、税務上は“継続的な売上の発生”を意味することが多い

8.3 前払式支払手段（資金決済法）：ポイント/残高を自前で発行する前に

「アプリ内ポイント」「チャージ残高」「地域通貨」など、前払いでお金を預かる設計をすると、資金決済法上の論点が出ます。
実装の難しさより、利用者保護の枠組みが重くなることが多いので、よほど理由がない限り、最初は避けるのが無難です。

ここは特に個別判断が必要なので、一次情報（条文）と専門家への相談を推奨します。

9. PAY.JPを例に：最小の実装イメージ（“経験なし”でも読み解ける粒度）

ここからは、具体例として PAY.JP を取り上げます。
理由は単純で、公式ドキュメントが読みやすく、サンプルも揃っているからです。

9.1 トークン化 → サーバサイド課金（最小）

PAY.JPドキュメントでは、トークンを使った課金（Charge作成）の例が示されています。
例えば Python だと以下のような形です（鍵は環境変数で管理）。

import os
import payjp

payjp.api_key = os.environ["PAYJP_SECRET_KEY"]  # 絶対にフロントに置かない
token_id = "tok_xxxxxxxxxxxxx"                  # payjp.js / Checkout 等で作る「使い捨てトークン」

charge = payjp.Charge.create(
    amount=3500,
    card=token_id,
    currency="jpy",
)

print(charge.id, charge.paid)

9.2 3Dセキュアを考慮すると、フロント側の入力要件が増える

3Dセキュアを行う場合、カード名義や連絡先（メール/電話）が求められるケースがあるため、UI設計に影響します。
実装を始める前に「必要項目」を把握しておくのが重要です。

9.3 Webhook：運用の中心（遅延・重複・再送がある前提）

Webhookは「成功したら送られてくる便利通知」ではなく、状態を確定させる基盤です。
PAY.JPドキュメントには、HTTPS推奨、リトライ、重複への対応などが具体的に書かれています。
この章（Webhook）は、実装に入る前に一度読んでおく価値があります。

10. まとめ：社会人が決済を扱うときの“品位ある”現実解

最後に、少しだけ価値判断を書いて終わります。

  • 決済は、技術的には「APIを叩く」話に見えるが、実態は 社会制度（法律・税・契約・信用）をソフトウェアに落とす仕事である。
  • だからこそ、「小さく始める」ときほど、責任範囲を狭くできる手段（プラットフォーム/決済リンク）から入るのは合理的。
  • それでもAPI組み込みが必要なときは、まず 状態遷移・Webhook・べき等性を設計し、カード情報は非保持化し、表示義務（特商法）と税務（消費税/インボイス等）を確認する。

付録：リリース前チェックリスト（コピペ用）

  • 技術
    • カード情報を自サーバに送っていない（トークン化）
    • Webhookの正当性確認を実装
    • イベントID等で重複排除（べき等）
    • 返金フロー（全額/一部）と台帳更新
    • 監査ログ（管理画面操作ログ、返金理由）
  • UX
    • 支払い失敗時に「次の行動」が分かる
    • 認証中/処理中の待ちを説明できる（3Dセキュア）
    • 購入完了＝提供完了 になっていない（状態遷移）
  • 法務（主にB2C）
    • 特商法：広告/最終確認画面の表示事項が揃っている
    • 返品・解約条件が明確（特に定期購入）
  • 税務
    • 売上・手数料・返金の記帳方法を決めた
    • 消費税（免税点/課税事業者/インボイス）を確認した
    • 領収書/請求書/インボイスの方針を決めた
  • 組織（大学・会社）
    • 兼業規程/会計規程/COI/寄付規程など、所属先の手続きを確認した

参考資料（一次情報中心）

以上です。誤りがあればご指摘ください（一次情報を確認のうえ修正します）。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?