LINE Pay終了後の決済設計。物販・予約・デジタル課金を分けて選ぶ

日本国内のLINE Payは2025年4月30日に終了しました。これからLINEを入口に購入や予約を受け付ける場合は、商品、既存の注文管理、決済後の業務から支払い方式を選び直します。国内終了の案内を、台湾・タイのLINE Payまで終了したという意味で扱わないことも必要です。LINEヤフーの発表で対象地域を確認できます。

本記事では2026年9月8日時点の公式仕様を基に、ECや予約の担当者が開発範囲を判断できるよう、決済の組み込み方を整理します。手数料や利用承認の条件は、採用する決済サービスの契約で確認する項目です。

支払い方法を選ぶ前に、何を売るかを分類する

「LINEの中で払う」という要望だけでは、適切な方式を決められません。物品、来店サービス、デジタルコンテンツでは、対象になる決済機能と購入後の仕事が異なります。

対象	構成の候補	主に確認すること
既存ECの商品	LINEから既存カート・注文履歴へ案内	会員連携、カート保持、戻り先
新しい物販・来店予約	自社Webの注文処理に外部決済を接続	在庫・予約枠と支払いの整合、取消・返金
対象の消耗型デジタル商品	認証済ミニアプリのアプリ内課金	対象条件、申請、付与の管理
定期課金を伴うサービス	商材と提供形態に合う決済を個別確認	継続・停止、利用権、規約上の条件

アプリ内課金は、現在のミニアプリで提供される消耗型デジタルコンテンツ向けです。飲食予約の事前決済をIAPで処理する、という設計にはできません。アプリ内課金の条件を確認し、外部決済と同じ機能として比較しないでください。

構成1：既存ECの決済を使い続ける

すでにECのカート、決済、配送管理が動いているなら、LINEからその購入フローへ案内する方法があります。ミニアプリのために注文DBを新設すると、在庫や返品処理まで二重に管理することになるため、現在の基盤を再利用できるかを確認します。

この構成でも、LINEから開いたときにログイン状態が保たれるか、カートが消えないか、購入後にどこへ戻るかは検証します。LINEユーザーとEC会員が連携済みでも、ブラウザのセッションが同じになるとは限りません。会員連携と画面のログイン状態を分けて確認します。

導入範囲は「決済を作り直す」より、会員と注文の対応付け、LINEからの入口、購入完了後の案内になる場合があります。ECのLINE連携の段階別構成で、追加する機能を整理してください。

構成2：Webの注文処理へ外部決済を組み込む

LINE Developersの決済説明では、その他の決済方式を一般のWebページと同様に実装し、外部で決済した後はミニアプリへ戻るよう案内されています。決済アプリや別ドメインへ移ることを含め、往復の操作を設計する必要があります。

採用するサービスでは、対象商材、加盟店契約、対応端末、継続課金、取消・返金API、手数料を確認します。外部決済を使っても、LINEミニアプリ側のポリシーや、決済事業者・ストア等の適用条件がなくなるわけではありません。特にデジタル商品を外部決済へ案内する可否は、商品の提供形態と現在の条件を確認して決めます。

戻ってきた画面だけで、支払い完了にしない

決済後の戻り先URLは利用者向けの案内です。自社サーバーでは、決済サービスからの通知や照会を使って結果を確認し、注文と照合します。画面のパラメータだけを信じて「支払い済み」に変更する構成は避けます。

利用者が決済アプリで支払った直後に画面を閉じても、注文を確認できるようにします。結果が確認中なら「未払い」と断定して再購入を促さず、確認中の表示と再確認の入口を用意します。

架空例：予約枠の確保と前払いを組み合わせる

店舗の予約枠を一定時間仮押さえして、支払い確認後に予約を確定する構成を考えます。このとき、決済待ちの間に枠を解放する条件と、遅れて成功通知が来た場合の対応を決めなければなりません。

予約の状態	決済の状態	業務上の判断例
仮押さえ中	処理中	期限を表示し、結果の確認を継続する
仮押さえ中	支払い確認済み	枠を確定し、予約番号を表示する
仮押さえ期限切れ	処理中・不明	枠の扱いと決済の照会を担当処理に載せる
枠を解放済み	遅れて支払い成功	再確保か返金か、定めた例外手順で判断する
予約取消済み	返金処理中	予約取消と返金完了を分けて案内する

「支払いに失敗した」と「結果を受け取れていない」は別です。この違いを管理画面で見分けられるようにすると、利用者へ二重の支払いを求める対応を防ぎやすくなります。

決済後の通知・取消・問い合わせまで見積もる

予約完了の案内と決済完了の案内は、誰がどの経路から送るかを決めます。アプリ内課金ではLINE側から決済通知が送られるため、同じ案内を自社から重ねる設計にはしません。外部決済でも決済事業者からメール等が出るなら、LINEには予約番号や利用日時など、業務上必要な情報を中心にします。

返金の可否と処理方法は決済方式によって異なります。自社予約を取消しただけで支払いまで取り消されると考えず、取消の受付、決済の取消・返金依頼、結果の確認、利用者への案内を別に管理します。

発注時の確認項目	明記する内容
正しい注文への支払い	注文番号、金額、会員をサーバーで照合する
二重処理への対策	同じ通知や操作でも二重請求・二重確定しない
通信が切れた場合	再表示・再照会で状態を確認できる
取消・返金	対応範囲、期限、担当者、処理結果の確認
売上との照合	自社注文と決済事業者の記録を突き合わせる
引き継ぎ	契約者、管理権限、秘密情報の保管、問い合わせ先

料金比較には初期実装だけでなく、月額費用、決済手数料、返金時の条件、問い合わせ対応の作業も含めます。機能を変更しやすい構成にする場合も、注文履歴と売上の連続性を保てるかを確認してください。

よくある質問

日本のLINE Payを新しいミニアプリに組み込めますか？

日本国内のLINE Payは2025年4月30日に終了しています。国内向けの新規構成では、商材に合う外部決済や、対象条件を満たすミニアプリのアプリ内課金を検討します。

既存ECの決済を必ず作り直す必要がありますか？

必須ではありません。LINEから既存のカートや注文履歴へ案内する構成を検討できます。会員連携、ログイン、カートの保持、購入後の戻り先は確認します。

決済後に完了画面へ戻ったら支払い済みにしてよいですか？

画面への遷移だけでは判断しません。サーバーで決済結果を確認し、注文番号・金額・会員との対応を照合してから業務状態を更新します。

予約を取り消せば決済も自動で返金されますか？

そのように実装・契約されているかによります。予約取消と決済の取消・返金は別の状態として管理し、処理結果まで確認して利用者に案内します。

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

TodoONadaでは、LINEを入口にした注文・予約と決済基盤の接続を支援しています。既存決済を再利用する構成から、会員連携・取消・返金を含む開発まで相談できます。

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