LINEミニアプリのアプリ内課金。利用条件・申請・購入処理の設計

LINEミニアプリのアプリ内課金は、LINEの画面で販売するあらゆる商品の決済手段ではありません。2026年9月8日時点では、認証済ミニアプリ内で提供する消耗型のデジタルコンテンツが対象です。飲食の事前決済や物品販売、継続課金を、同じ機能で扱う前提にしないでください。

発注時には、商品が対象かを確認したうえで、申請、購入後の付与、問い合わせまでを見積もります。購入ボタンだけが動く状態と、売上を伴うサービスを運営できる状態には差があります。

商品・地域・環境の条件を先に確認する

公式のアプリ内課金概要では、日本向けの対象地域・事業者所在地や、利用者のLINE環境などの条件が定められています。認証済みであることに加え、申請承認と対応環境を満たす必要があります。

企画している商品	最初に確認すること
使い切りのデジタルアイテム	対象条件と、提供する内容が消耗型に該当するか
買い切りで永久利用する機能	現行の消耗型だけで企画を表現できると決めつけない
月額会員・定期購読	現行機能を自動更新課金として扱わない
飲食、来店サービス、物販	デジタルコンテンツ課金と分けて決済方式を検討する

利用者の端末が対象外なら、購入できない理由と閲覧可能な範囲を表示します。売上計画の対象者数も、「ミニアプリの全利用者」から、実際に購入できる環境の利用者を分けて考えます。

利用申請とミニアプリの認証審査は別の工程

未認証ミニアプリでもアプリ内課金の利用申請は可能です。申請が承認された後、設定と開発環境でのテストを進め、課金機能を含むミニアプリの認証審査を受けます。既に認証済みのアプリへ課金を追加する場合にも再審査が必要です。

工程	発注側が準備するもの	開発側と確認すること
利用申請	正確な事業者情報、サービス内容	誰の管理権限で申請するか
費用確認	申請画面に表示される手数料条件	売上・手数料・受取額の計算方法
開発とテスト	商品の意味、付与数量、問い合わせ窓口	テスト環境、購入結果の記録方法
認証審査	操作手順と申請内容	課金機能を含めた審査・修正範囲
本番運用	売上確認と利用者対応の担当	付与漏れや障害を調べる手順

手数料は一般的なカード決済の率を流用せず、実際の利用申請時に表示される条件を確認します。価格表示や商品の登録にもプラットフォーム側の仕様があるため、自由な金額を入力できる一般ECカートと同じ見積もりにしません。

購入予約・決済完了・アイテム付与を別の状態にする

購入処理では、画面上の成功表示だけでアイテムを付与しない設計が必要です。購入予約は課金完了の保証ではありません。サーバーで購入結果を確認し、注文IDと付与済みの記録を照合します。

以下は業務状態を管理するための設計例です。実際のAPI名やイベント仕様は公式実装手順に合わせます。

自社で管理する状態	保存する情報	利用者に見せる内容
購入を開始	会員、商品、注文との対応	どの商品を購入しようとしているか
結果確認中	注文ID、最終確認日時	連打せず結果を確認できる案内
付与済み	付与数量、付与日時、注文ID	使える残数や利用履歴
中断・失敗	確認できた結果と理由	再試行できるか、問い合わせが必要か
調査中	問い合わせと取引の対応	調査状況と確認方法

開発ガイドラインでは、購入予約時のアクセストークン検証が必須です。またWebhookの署名確認や、注文IDを使う重複排除が示されています。正規の通知であっても、同じ購入結果が再送されることを想定して、残数の加算を一度だけにします。

架空例：消耗型のデジタル利用券を扱う

対象として承認される消耗型コンテンツに、使い切りの利用回数を付与するサービスを想定します。購入画面を閉じた直後にWebhookが届いても、サーバーは注文と会員を照合して付与を完了し、利用者が再訪したときに残数を表示します。

同じWebhookがもう一度届いた場合は、付与済み注文として記録し、残数を再加算しません。反対に、購入済みなのに付与記録がなければ、問い合わせ担当が注文IDを起点に調べられるようにします。利用回数の消費も別の履歴として残すと、「購入」「付与」「利用」のどこで問題が起きたかを追えます。

これは実装の考え方を示す架空例です。特定商品の利用承認や収益性を示すものではありません。

通知と返金の窓口も公開前に決める

アプリ内課金にはプラットフォームから送られる決済通知があります。同じ意味の通知を自社の公式アカウントから重ねて送ると、利用者が二重購入したと誤解する可能性があります。自社から何を案内するかは、決済通知とコンテンツの利用案内を分けて決めます。

完了した決済のキャンセルは、LINEヤフー側で受け付ける構造ではありません。公式説明では、利用者がアプリストアの払い戻し手続きへ進むよう案内されています。自社サービスの利用状況調査と、ストアへの払い戻し申請を混同せず、問い合わせ担当が案内する範囲を整えます。

受入確認は購入成功以外も含める

テスト場面	合格条件の例
対応外の環境	購入できない理由を示し、壊れたボタンを出さない
利用者が途中で閉じる	次回起動時に注文と付与状態を確認できる
Webhookが重複する	同じ注文に対して一度だけ付与される
不正な通知が届く	署名等の検証を通らない処理で付与されない
決済済み・付与未完了	担当者が注文を特定し復旧判断できる
問い合わせが来る	自社調査とストア手続きの案内を分けられる

課金が対象外の商品を扱う場合は、LINE Pay終了後の決済設計で外部決済を含む構成を確認してください。

よくある質問

飲食店の予約金もアプリ内課金で支払えますか？

本記事で扱うアプリ内課金は、現行では消耗型デジタルコンテンツが対象です。飲食や来店サービスの予約金は、その商品の条件に合う決済方式を別に検討します。

未認証の間はアプリ内課金の準備を始められませんか？

利用申請は未認証でも可能です。承認後に設定と開発・テストを進められますが、一般ユーザー向けの公開には課金機能を含む認証審査が必要です。

購入画面の成功表示でアイテムを付与してよいですか？

画面の表示だけで判断しません。サーバーで購入結果を確認し、注文IDを使って付与済みかを照合します。通知の再送があっても二重に付与しないようにします。

すでに認証済みなら課金を追加してすぐ公開できますか？

課金機能を組み込んだ場合は再度認証審査が必要です。利用申請、設定、テスト、審査対応を公開予定に含めてください。

この記事に関連するサービス

TodoONadaでは、販売する商品の条件整理から、ミニアプリの購入処理・付与管理・問い合わせ運用まで支援しています。アプリ内課金を使う範囲と外部決済との分担から相談できます。

LINEアプリ開発のサービス・相談窓口を見る