LINEPay開発、まだ続けております。
いわゆるリリース後の改修、改善ステージではあるのですが、通常のWebアプリだと簡単にできることがLIFF＆トークルーム構成だとできないこともあり・・・・。
にて、決済実装（キャンセル対応あり）まで進みました。この時点で、1点ほど何とかしたいところが。
この時点ではトークルーム上のメッセージからGETで自システムの処理へ移動し、自処理内で決済まで進めてもOK判定がでた場合に、LINEPayの決済予約API（当方、まだV2でーす）を実行、戻ってきたURLにリダイレクトしていました。
そうすると、ユーザーが途中でLINEPayアプリの利用に切り替えると、自システムの処理のために開いた内部ブラウザが閉じられないのです！（だって、GETだもの）
直近の改修で、さらに決済前の自システム処理に手が入ることになったので、なんとか改善できないものかと、
と模索しました。
いずれも、できませぬ。
jsで閉じるとしたら「window.close」ですが、ご承知の通り、jsで開けたwindowは閉じられますが、通常遷移で開いたwindowは閉じられません。
困ったことに、トークルーム上のURIアクションはGETのみ（URIアクションは”開く”形式なので）
「POSTしたいならpostbackアクションあるじゃん」と言われるかもしれませんが、
wehookでメッセージをサクサクさばくための仕掛けとコンフリクトするんで、できません。撃沈です。
また、2020年に入ってから、今回の修正をしていると、paymentUrl.appへ遷移しないと、キャンセル発生時の処理がiOSとAndroidで違いがあり（注：弊社が使用しているテスト端末上で発生しているのを確認しているだけなので、他のモデルなら大丈夫かもしれませんが）、内部ブラウザ＝＞アプリ遷移が確定し、アプリが立ち上がった後ろに内部ブラウザが立ちっぱなしになることが確定。
おまけに、決済完了時の挙動が、やはりiOSとAndroidで違いが。内部ブラウザが閉じたり、閉じなかったりするのです。（注：上記と同じで、他のモデルなら大丈夫かも？？）
最終的には
で、なんとなーく、遷移していてもうまくいっているように見せています。
自システムを挟まなければ、悩まなくていいのですが、リアル店舗がかかわったりすると、
確実に決済前にチェック処理が必要になることも多々あるかと思います。
LINEPayの決済導入や、LINEPayのオンライン決済とシステムの連携など、お困りの方は、是非、弊社にご相談ください。
ご相談は、こちらから。