LINEで開いたStripeの決済ページが
動かない
（アプリ内ブラウザ）

by
  • LINEのリンクをタップすると、SafariではなくLINE内蔵の簡易ブラウザ（WebView）が開きます。
  • WebViewはCookieの保管場所がSafariと分離されており、複数ドメインをまたぐStripeの決済処理でセッションが途切れます。
  • 解決策はLINE内で開かず、SafariやChromeなど外部ブラウザで開き直すことです。

関連記事

1. LINEに送った決済リンクが開かない

LINEで送られてきたStripe決済リンクをタップしたら画面の読み込みが終わらなかったり、ボタンが少ないことがあります。

LINEのStripe決済が動かない理由 LINEでタップ → WebViewが開く 読み込み 終わらない 途中で止まる Safariで 開き直す → 正常に動作 原因はWebViewの技術的な制約。リンクの不具合ではない。

同じリンクでも、SafariやChromeで開き直すと、あっさり表示されます。

これは、リンクの間違いではなく、「LINEの中でWebページを開く」こと自体に技術的な制約があります。

1.1. LINEの中に「別のブラウザ」が入っている

LINEに届いたリンクをタップすると、SafariやChromeがではなく、LINE自身の画面の中に、簡易的なブラウザが開きます。

これをWebView（ウェブビュー）といいます。
アプリに埋め込まれた、いわば「アプリ専用の簡易ブラウザ」です。

WebViewはSafariやChromeと似た見た目ですが、同じものではありません。

2. なぜStripeの決済ページで問題が起きるのか

Stripeの決済ページは「ただのHTMLを表示するだけ」ではなく、Cookie、iframe、ポップアップ、外部認証、認証後の復帰といった複数の仕組みを組み合わせて動いています。

なぜStripe決済が動かないのか Stripe Cookie / iframe ポップアップ / 外部認証 ❶ ポップアップ 外部遷移が WebViewで不安定 ❷ Cookie分離 SafariのCookieと 完全に切り離されている ❸ ITP クロスドメインCookieを 強くブロック ❹ iframe干渉 WebView自体が 埋め込み構造 → 単独または複合で発生 「読み込み終わらない」「途中で止まる」

Stripeの決済ページは、見た目はシンプルでも、裏側でいくつかの複雑な仕組みを動かしています。
フルブラウザはこれを問題なく扱いますが、WebViewはその前提を満たせない場合があります1。

クレジットカード決済では「本人確認のため別の画面に飛んで、戻ってくる」という流れが必要なことがあります。
この流れは、SafariやChromeで動作するように検証されていますが、WebViewではポップアップを開いたり、外部アプリへ遷移して戻ってきたりする処理が不安定です。

Stripeのドキュメントでは、Express Checkout Element（クイック決済機能）について「アプリ内WebViewではサポートが限定的で、多くの決済手段はポップアップウィンドウを必要とするため、正しく動作しないことがある」と案内しています2。

  • Googleの公式ドキュメントによると「WebViewはフルブラウザの機能を一部欠いており、外部のウェブコンテンツを表示したい場合はCustom Tabsを検討すべき」と書かれています3。
  • LINEの開発者向けドキュメントでも、アプリ内ブラウザでは一部の画面遷移機能が使えないと明記されています4。

これはStripe側が「WebViewでの動作を保証しない」という意味でもあります。

2.1. CookieとセッションがSafariと切り離されている

ウェブサービスが「あなたは今ログイン中」「この決済フローの途中」といった情報を覚えておくのに使うのがCookieです。

iPhoneの場合、WebViewのCookie保管場所はSafariと完全に分離されています。
Stripeの決済は複数のドメインをまたいで動くため、Cookieの制限が「認証済みのはずなのにセッションが切れた状態になる」「決済の途中で情報が引き継がれない」という現象につながります。

iOSのWKWebViewはSafariとは別プロセスで動作するため、SafariのCookieストアとは独立した領域にCookieを保持します5。

さらにAppleのWebKitエンジンには、別ドメインのCookieを強くブロックするITPという仕組みが入っています。
ITPはIntelligent Tracking Preventionの略で、クロスサイト追跡を防ぐためのものです6。

2.2. iframeの入れ子問題

さらに、Stripeはカード情報を安全に扱うため、決済フォームの内部にiframeを使っています。

iframeとはページの中に別のページを埋め込む仕組みのことです。
Stripe自身が「Payment Elementを別のiframeの中に配置することは避けるべき」と案内しているのは、リダイレクトが必要な決済手段と衝突するためです7。

WebViewという「すでに何かに埋め込まれた状態」で動くブラウザでは、このiframeとの干渉が起きやすくなります。

3. なぜLINEはWebViewを使うのか

「最初からSafariで開けばいいのでは」と思う方もいるかもしれません。

なぜLINEはWebViewを使うのか メリット 📱 アプリ外に出ない 体験が途切れない 📉 離脱率が下がる UX上有利なケース多い しかし 限界 💳 決済のような複雑処理 には向いていない ⚙ LIFFと通常WebViewで 使える機能に差がある 設計上の判断。決済には外部ブラウザが適切。

LINEがWebViewを使うのは、ユーザーをアプリの外に出さずに体験を完結させるためです。
アプリ内で読めるほうが離脱率が下がり、ユーザー体験として有利なケースも多いからです。

ただし、決済のような複雑な処理には向いていません。

LINE自体も用途に応じてLIFF（ライフ、LINE内で動くアプリ開発フレームワーク）と通常のアプリ内ブラウザを使い分けており、それぞれ使える機能に差があることをドキュメントで認めています8。
さらに、LIFFブラウザからURLを開くliff.openWindow()は外部ブラウザでの動作が保証されておらず、LINE バージョン 14.20.0 以降から Universal Links や App Links を開く際の挙動も変化しています9。

4. まとめ

LINEのアプリ内ブラウザでStripe決済が動かない技術的な理由は、おもに4点です。

WebViewがポップアップや外部への画面遷移を正しく処理できないこと、Cookieの保管場所がSafariと切り離されていてセッションが引き継がれないこと、複数ドメインをまたぐCookieがブロックされること、iframeの入れ子による干渉。
これらが単独または複合で起きた結果が、「読み込みが終わらない」「途中で止まる」という症状です。

Stripeのような決済サービスをLINE経由で使う場合、「外部ブラウザで開く」という選択が最も安定した動作につながります。
これは不具合ではなく、WebViewという仕組みの設計上の限界です10。

  1. AndroidのCustom Tabsはユーザーのデフォルトブラウザのインスタンスとして動作するため、Cookieを共有でき、ブラウザの全機能が使えます。一方WebViewはChromeとコードを共有しても「データは共有しない」とGoogleが明示しています。 – WebView overview
  2. Stripe の公式ドキュメントには「Express Checkout Element has limited support in in-app webviews. Many payment methods require popup windows and might not function correctly.」と記載されています。モバイルアプリへの組み込みにはiOS SDKまたはAndroid SDKの利用が推奨されています。 – Express Checkout Element
  3. Android Developers では「外部URLへリンクする場合には Custom Tabs の利用を推奨する」と明記されており、WebView はあくまでアプリが完全にコントロールするコンテンツ向けとされています。 – Use web content within your Android app
  4. LINE Developers の公式ドキュメントでは、LIFFブラウザとLINEアプリ内ブラウザは別物であり、利用できる機能に差があると明記されています。外部サイトへのポップアップ表示などはLIFFブラウザ側の機能であり、通常のアプリ内ブラウザでは使えません。 – The differences between LIFF browser and LINE’s in-app browser
  5. Apple Developer Forumsでも、WKWebView は別プロセス上で動作するため、HTTPCookieStorage（アプリ側のCookie領域）との同期が自動では行われないことが確認されています。開発者が明示的に同期処理を実装しないかぎり、SafariのCookieはWebViewに引き継がれません。 – How to synchronize cookies in WKWebview
  6. WebKitのITPは2017年にSafari向けに導入され、以降継続的に強化されてきました。2020年のITP更新では「サードパーティCookieをデフォルトで全面ブロック」する仕様となっています。 – Full Third-Party Cookie Blocking and More
  7. Stripeの公式ドキュメントには「Avoid placing the Payment Element within another iframe because some payment methods require a redirect to another page for payment confirmation.」と記載されています。 – Payment Element integration best practices
  8. LINE Developers のドキュメントでは、LIFFブラウザはWKWebView（iOS）およびAndroid WebViewの仕様に従うと説明されています。また外部ブラウザで開いた場合との機能差も明示されており、環境によって利用できるAPIが異なります。 – The differences between LIFF browser and external browser
  9. LIFF v2 APIリファレンスには「Use of liff.openWindow() in an external browser isn’t guaranteed.」と記載されており、Universal LinksやApp Linksを開く挙動はLINEのバージョンとparams.externalの設定によって異なります。 – LIFF v2 API reference
  10. Androidでは WebView の代替として Custom Tabs が推奨されており、これはユーザーのデフォルトブラウザのCookieやセッションを共有します。サードパーティのサインインフローや外部URLを開く場面に適しているとされています。 – In-app browsing using Embedded Web