---
title: お金・決済系
description: ポイント・電子マネー・送金機能で確認すべきこと。「ポイント」という言葉が出た時点で確認対象
sidebar:
  label: 概要
---

「貯まったポイントに有効期限を設けたい」「ユーザー同士でお金を送り合えるようにしたい」「投げ銭でクリエイターを応援できるようにしたい」。どれも技術的には難しくありません。**お金が絡む機能は、実装の難易度よりも法的なリスクが問題になります。**

しかもこの領域は、後戻りのコストが極端に高いのが特徴です。「他社でも使えるようにする」という一見シンプルな仕様変更が事前登録（審査に数ヶ月）を必要としたり、実装済みの退会フローが払い戻し禁止規定に抵触して作り直しになったりします。仕様が固まった段階でアラートを出せれば、いずれも回避できます。

## こんな言葉が仕様に出たら

- **ポイント** / マイル / コイン / チケット（呼び方は何であれ）
- チャージ / 前払い / 残高
- 送金 / 投げ銭 / ギフト / 換金 / 出金
- 有効期限 / 失効
- 退会時の返金

## 機能別の確認事項

| 実装しようとしている機能 | 主な確認事項 |
|---|---|
| [ポイント発行（購入特典・おまけ含む）](/features/money/point-issuance) | **付与型（購入特典）か、先払いのチャージ型か**を最初に確認。対価性の有無。有効期限を6ヶ月以内にするか6ヶ月超にするか（6ヶ月超は資金決済法の対象）。キャンペーンのおまけ分もチャージと一体で扱われうる |
| [チャージ型電子マネー](/features/money/prepaid-emoney) | **有効期限6ヶ月超なら財務局への届出義務**。基準日（3月末・9月末）の未使用残高が**1,000万円超で供託義務**。未使用残高の総量を集計できるDB設計になっているか |
| [他社でもポイントを使えるようにする](/features/money/third-party-points) | **サービス開始前の事前登録が必要**（自家型は事後届出だが、第三者型は事前登録）。審査に数ヶ月かかるため、仕様変更の段階でリリース計画に織り込む |
| [ユーザー間送金・投げ銭機能](/features/money/p2p-transfer) | **換金・出金できるかが分岐点**。できるなら金融庁への資金移動業登録が必要。「サービス内ポイントだから」は通じない。対価スキームにするなら「対価は何か」を明確にする |
| [退会時のポイント残高返金](/features/money/point-refund) | **現金での払い戻しは原則禁止**（資金決済法第20条）。退会フローに返金ロジックを入れる前に確認する |

## このカテゴリの勘所

**「ポイント」という日本語は2つの別物を指します。** 購入後に付与される特典（付与型）と、ユーザーが先に払い込んだ残高（チャージ型）です。前者と後者では、法的な扱いも経理処理も根本的に違います。仕様を受け取ったら、まずどちらなのかを確認してください。これがこのカテゴリすべての出発点です。

**有効期限6ヶ月が境界線です。** 6ヶ月以内なら資金決済法の適用対象外（供託義務も届出義務もなし）、1日でも超えると適用対象になります。供託のキャッシュフロー負担を避けるか、ユーザーの利便性を取るかはビジネス判断なので、法務・経営層を含めて決める話です。

**換金できるかどうかが、もう一つの境界線です。** ユーザー間でやりとりできるだけなら送金にはあたらなくても、それを現金やギフト券に換えられるなら実質的な送金とみなされうる。「将来的に換金できるようにしたい」という要件が出た段階で法務に相談してください。

## あわせて確認

- DB設計に入るなら → [残高DB設計](/features/accounting/balance-db)（経理と照合できる設計になっているか）
- 企画段階の確認漏れは → [フェーズ1：機能企画・要件定義時](/checklist/phase-1-planning)
- 運用中の定期確認は → [フェーズ5：運用継続中](/checklist/phase-5-operation)（供託判定・失効処理）

{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}