LINEミニアプリに決済を実装するなら？LINE Pay終了後の選択肢をStripe・PAY.JP・GMO-PGで比較

LINEミニアプリに決済機能を組み込もうとして、まず最初につまずくのが「LINE Payが使えない」という事実です。

2025年4月30日、LINEヤフーは日本国内における「LINE Pay」のサービスを終了しました。決済機能はPayPayへ一本化され、LINEミニアプリに決済を実装する場合は外部決済サービスを個別に導入する必要があります。

では何を選べばいいのか。検索するとStripe・PAY.JP・GMOペイメントゲートウェイ（以下GMO-PG）あたりが定番として挙がりますが、それぞれ設計思想もドキュメントの充実度も料金体系も異なり、LINEミニアプリという「LIFF（WebView）上で動く」特殊な環境への実装しやすさも変わってきます。

この記事では、LINEミニアプリに決済を組み込む前提で、Stripe・PAY.JP・GMO-PGの3社を「API設計思想」「ドキュメント・SDKの充実度」「料金体系」「LINEミニアプリ実装との相性」の4軸で比較します。あわせて、LIFF特有の実装上の注意点もまとめました。

LINEミニアプリの決済、今どうなっているのか

LINE Pay終了の経緯とPayPayへの一本化

LINEヤフーは2024年6月13日、国内の送金・決済サービスを「PayPay」に一本化する方針を発表し、2025年4月30日までに「LINE Pay」の国内サービスを順次終了しました。LINE Payの残高は希望者向けにPayPay残高への移行が案内され、決済機能そのものはPayPayに引き継がれる形となっています（なお、タイ・台湾のLINE Payはこの終了の対象外で、現地では引き続き利用できます）。

なお、PayPay自体も「PayPay for Developers」として決済APIを法人・個人開発者向けに提供しています。ただしPayPayはQRコード決済という特定の決済手段（自社ブランド）に特化したサービスであり、複数の決済手段を横断的に扱う汎用の決済ゲートウェイとは性質が異なります。本記事では、複数の決済手段を横断的に導入する際の技術選定という観点から、Stripe・PAY.JP・GMO-PGの3社を比較対象とします。

現在選べる決済方式の全体像

現時点でLINEミニアプリに組み込める決済方式は、大きく分けて2パターンです。

1. 外部決済サービス: Stripe・PAY.JP・GMO-PG・PayPay for Developers等を使い、通常のWebページと同様の実装で決済を組み込む方式
2. アプリ内課金（In-App Purchase）: デジタルコンテンツの購入に限定して使える仕組みで、App Store/Google Playの課金機構を通じて処理される（日本のみ対応）

物理商品や実サービスの決済であれば1の外部決済サービスを選ぶことになります。PayPay単体で十分なケース（決済手段をPayPayに限定してよい場合）であればPayPay for Developersも選択肢になりますが、クレジットカード決済や複数の決済手段を横断的に扱いたい場合は、本記事で比較するStripe・PAY.JP・GMO-PGのようなゲートウェイ型サービスを検討することになります。

LINEミニアプリに決済を組み込む際の技術的制約

決済サービスそのものの比較に入る前に、LINEミニアプリ（LIFF）という実行環境特有の制約を押さえておきます。ここは一般的なWebアプリへの決済実装と異なる、見落としやすいポイントです。

LIFF（WebView）内での決済フローの基本

LIFF（LINEミニアプリ）はLINEアプリに内蔵されたWebViewで動作します。外部決済サービスのページに遷移する際は、LIFF SDKの liff.openWindow() を使って外部ブラウザを明示的に指定するのが基本パターンです。

import liff from "@line/liff";

async function goToCheckout(checkoutUrl: string) {
  await liff.ready;
  // external: true で外部ブラウザ（Safari/Chrome等）を明示的に指定する
  liff.openWindow({
    url: checkoutUrl,
    external: true,
  });
}

LIFF内のWebViewのまま遷移すると、3Dセキュア認証のような追加のリダイレクトを挟む決済フローで、Cookieやポップアップの制約に引っかかり正常に完了できないケースが報告されています。この挙動はLINE公式ドキュメントで網羅的に明記されているわけではなく、OSやLINEアプリのバージョンによって差異が出る可能性があるため、実装時は必ず実機で検証することをおすすめします。

外部ブラウザ遷移・LINE側の審査要件で気をつけるポイント

決済完了後にLINEミニアプリへ戻す実装は、決済サービス側のリダイレクトURL指定機能にLIFF URLを指定するのが基本です。Stripe Checkoutを例にすると、以下のように success_url / cancel_url にLIFF URLを指定します。

// 決済サービス側の戻り先URLにLIFF URLを指定する（Stripe Checkoutの例）
const session = await stripe.checkout.sessions.create({
  mode: "payment",
  line_items: [/* ... */],
  success_url: "https://liff.line.me/{LIFF_ID}?status=success",
  cancel_url: "https://liff.line.me/{LIFF_ID}?status=cancel",
});

戻り先のLIFFアプリ側では、パラメータを見て liff.closeWindow() でLIFFブラウザを閉じ、LINEのトーク画面に戻す実装が一般的です。

// LIFFアプリ側（success_urlで開かれるページ）での戻り処理
import liff from "@line/liff";

async function handleReturn() {
  await liff.init({ liffId: process.env.NEXT_PUBLIC_LIFF_ID! });
  const params = new URLSearchParams(window.location.search);
  if (params.get("status") === "success" && liff.isInClient()) {
    // liff.closeWindow() は「現在開いているLIFFブラウザを閉じてLINEのトーク画面に戻る」API
    liff.closeWindow();
  }
}

ただし、外部ブラウザで開いた決済ページからLIFF URLへリダイレクトした際、LINEアプリが自動的に前面に戻ってくるかどうかはOS・LINEアプリのバージョンに依存し、ブラウザ内に留まったままになることもあります。なお、LIFF公式リファレンスでは「外部ブラウザでの liff.closeWindow() の動作は保証されない」と明記されています。決済完了後にLIFF URLへリダイレクトした際、LINEアプリのLIFF内ブラウザに戻らず外部ブラウザに留まったままの場合、liff.closeWindow() が想定通りに動作しない可能性があるため、公開前に必ず実機で確認してください。

また、LINEミニアプリはLINE Developersコンソールでの審査が必要です。決済機能そのものへの個別審査項目があるわけではありませんが、チャネル説明にサービス内容が正しく記載されているか等、一般的な審査要件は決済機能を含むミニアプリにも当然適用されます。

物理商品・サービス課金とデジタルコンテンツ課金（アプリ内課金）の切り分け

デジタルコンテンツ（電子書籍・ゲーム内アイテム等）の購入を伴う場合は、外部決済サービスではなくLINEミニアプリのアプリ内課金の利用が求められるケースがあります。この切り分けを誤ると審査で差し戻される可能性があるため、実装するサービスが「物理的な商品・実サービス」なのか「デジタルコンテンツ」なのかを最初に整理しておくことをおすすめします。

Stripe・PAY.JP・GMO-PGを4軸で比較する

ここからは3社を「API設計思想」「ドキュメント・SDKの充実度」「料金体系」「LINEミニアプリ実装との相性」の4軸で比較します。

API設計思想

Stripe（Payment Intentモデル）

import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: "<Stripeダッシュボードで確認した最新のバージョン>", // 例: 2026-06-24.dahlia 等、執筆時点の値をそのまま貼らない
});

const paymentIntent = await stripe.paymentIntents.create({
  amount: 1000, // 最小通貨単位（JPYはそのまま円）
  currency: "jpy",
  automatic_payment_methods: { enabled: true },
});

// client_secret をフロントエンドに返し、Stripe.js側で決済を確定する
return Response.json({ clientSecret: paymentIntent.client_secret });

Stripeの決済は「Payment Intent」という状態を持つオブジェクトを中心に設計されています。作成した時点では決済は完了しておらず、その後の確定・3Dセキュアなどの追加認証・失敗といった一連の状態遷移をPayment Intentが保持し続けます。1回の呼び出しで完結する設計ではない分やや複雑になりますが、追加認証を挟む決済や後からの状態確認に強い構造です。

PAY.JP（Chargeベース）

import payjp from "payjp"; // パッケージ名・メソッド名は公式ドキュメントで最新版をご確認ください

const client = payjp(process.env.PAYJP_SECRET_KEY!);

const charge = await client.charges.create({
  amount: 1000,
  currency: "jpy",
  card: token, // フロントでトークン化したカード情報
  capture: true,
});

PAY.JPはChargeオブジェクトを1回のAPI呼び出しで作成するだけで決済が完了する、シンプルな設計です。実装量が少なく学習コストも低い一方、Stripeのように決済途中の状態を細かく追跡する仕組みは薄いため、3Dセキュアや後からのキャプチャ処理を扱う場合は自前でステータス管理を組み込む必要があります。

GMOペイメントゲートウェイ（EntryTran → ExecTran）

// Step 1: 取引登録（EntryTran）— エンドポイントURL・パラメータ名は
// 契約形態や本番/テスト環境で異なるため、下記は設計思想を示す一例です
const entryRes = await fetch("https://pt01.mul-pay.jp/payment/EntryTran.idPass", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({
    ShopID: process.env.GMO_SHOP_ID!,
    ShopPass: process.env.GMO_SHOP_PASS!,
    OrderID: orderId,
    JobCd: "CAPTURE",
    Amount: "1000",
  }),
});
const entryParams = new URLSearchParams(await entryRes.text());
const accessId = entryParams.get("AccessID");
const accessPass = entryParams.get("AccessPass");

// Step 2: 決済実行（ExecTran）
const execRes = await fetch("https://pt01.mul-pay.jp/payment/ExecTran.idPass", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({
    AccessID: accessId!,
    AccessPass: accessPass!,
    OrderID: orderId,
    Method: "1",
    CardNo: cardNo, // 実運用ではトークン化を推奨
    Expire: expire,
    SecurityCode: securityCode,
  }),
});

GMO-PGは、取引情報を登録する「EntryTran」で取引ID（AccessID/AccessPass）を発行し、そのIDを使って決済を確定する「ExecTran」を呼び出す2段階設計です。決済確定前に金額や注文情報の整合性チェックを挟める利点がある一方、APIを2回呼び分ける手間とID管理が実装者側の負担になります。

ドキュメント・SDKの充実度

SDKとドキュメントの充実度には3社で明確な差があります。Stripeはstripe-nodeをはじめNode.js・Python・Ruby・PHP・Java・Go・.NETなど主要言語向けの公式SDKを揃え、TypeScript型定義もSDK内に同梱されているため型補完が効いた状態で実装できます。公式ドキュメントもAPIリファレンスと実装ガイドが統合され、言語別コードサンプルを切り替えられる点で開発者体験が高い部類です。

PAY.JPは国内サービスのため日本語ドキュメントが充実しており、Node.js・PHP・Ruby等の主要言語向けに公式SDKを提供していますが、対応言語数・型定義の網羅性はStripeほど広くはありません。

GMO-PGは従来型API（マルチペイメントサービス）に公式のNode.js/TypeScript SDKが用意されておらず、生HTTPでのリクエスト構築が前提です。ドキュメントもPDF形式の技術仕様書が中心で、対話的なAPIリファレンスは限定的なため、実装のキャッチアップに要する時間は他2社より長くなる傾向があります。

料金体系

3社とも決済手数料を主な収益源とする点は共通していますが、初期費用・月額費用の有無や手数料率の交渉余地に違いがあります。StripeとPAY.JPは初期費用・月額費用が無料で、決済手数料のみのシンプルな料金体系を採用しているケースが多く、取引額が小さいうちは導入しやすい傾向があります。GMO-PGは取引規模に応じた個別見積もりが可能で、大規模な取引ボリュームがある場合は手数料率を下げられる余地がありますが、その分契約プロセスは他2社より重くなりがちです。

料金体系は改定されることがあるため、この記事では詳細な数値までは掲載しません。導入検討時は各社の最新の料金ページで必ず確認してください。

LINEミニアプリ（Webベース）実装との相性

LINEミニアプリはWebベースで動作するため、3社とも「通常のWebページと同様の実装で組み込める」という点では共通しています。ただし前述のとおり、LIFF内WebViewからの外部ブラウザ遷移・戻り先URLの制御が必要になるため、リダイレクト型の決済ページ（Stripe Checkout等）を提供しているサービスの方が実装の見通しは立てやすいと言えます。GMO-PGのように取引登録・決済実行を自前のフォームで組み立てる設計の場合、LIFF内での画面遷移設計をより丁寧に作り込む必要があります。

ユースケース別のおすすめ

ここまでの比較を踏まえて、目的別にどのサービスが検討しやすいかを整理します。

とにかく早く・シンプルに実装したいなら

PAY.JPが候補になります。Chargeベースのシンプルな設計と初期費用無料の料金体系で、最短距離での実装がしやすい構成です。MVP開発やスモールスタートのプロジェクトに向いています。

国内の決済手段を幅広く網羅したいなら

GMO-PGが候補になります。クレジットカードに加えてコンビニ払い・キャリア決済・電子マネー等を1社で完結できる網羅性が強みで、実装コストと引き換えに決済手段の選択肢を広げられます。

将来的にグローバル展開・サブスク課金も見据えるなら

Stripeが候補になります。Payment Intentという状態管理の仕組みは、サブスクリプション課金や多通貨対応といった複雑な決済フローに拡張しやすい設計です。ドキュメント・SDKの充実度も高く、長期的な保守のしやすさという観点でも有利です。

実装時に気をつけたいチェックリスト

• LIFF内WebViewのまま決済ページに遷移せず、liff.openWindow({ external: true }) で外部ブラウザに明示的に遷移させているか
• 決済完了後の戻り先URLにLIFF URLを指定し、liff.closeWindow() 等で適切にLIFFアプリへ戻す導線を用意しているか
• 決済完了後のLINEアプリ復帰挙動をiOS/Android両方の実機で検証しているか（自動遷移の挙動はOS・LINEアプリのバージョンに依存するため）
• 実装するサービスが「物理商品・実サービス」か「デジタルコンテンツ」かを整理し、アプリ内課金が必要なケースを見落としていないか
• カード情報の取り扱いがPCI DSSの要件に抵触しない実装（トークン化・決済サービス側のフォーム利用等）になっているか
• 各社の料金体系・APIバージョンを公式ドキュメントの最新情報で確認したか

まとめ

LINE Payが2025年4月に国内サービスを終了したことで、LINEミニアプリに決済を組み込む際は外部決済サービスの個別導入が前提になりました。Stripe・PAY.JP・GMO-PGはそれぞれ「グローバル最新設計・拡張性重視のStripe」「シンプルさ・低コストのPAY.JP」「国内決済手段の網羅性重視のGMO-PG」という異なる立ち位置にあり、どれが正解というよりは、実装するサービスの性質（スピード重視か、決済手段の幅を求めるか、将来のグローバル展開を見据えるか）によって選ぶべきサービスが変わってきます。

あわせて、LINEミニアプリ特有の制約——LIFF内WebViewからの外部ブラウザ遷移、決済完了後の戻り導線、アプリ内課金との切り分け——は、決済サービス選定と同じくらい実装の成否を左右するポイントです。決済サービスを選ぶ前に、まずはLIFFという実行環境の制約を把握しておくことをおすすめします。

Amanityでは、LINEミニアプリの企画・設計から決済連携を含む実装まで一貫して支援しています。決済サービスの選定や実装でお悩みの方は、お気軽にお問い合わせください。