完全無料でPayPayオンライン決済をWooCommerceに導入できます。

購入手続きページがCheckout Blocksで表示されている場合、有効化プラグインが多いとPayPayとの通信が失敗することが多発します。プラグインの数を減らすか、「クラシック購入手続き」に変更してください。

(2025年7月12日)
Version2.10 webhook関連を見直してセキュリティを強化しました。
Version 2.05からクリック一つで更新できるようにしてあります。
もし、更新できなかった場合は、dip.mamekichi-an.com からダウンロードしてください。
dip.mamekichi-an.com には本プラグイン以外にも便利なプラグインがあります。
今後は、こちらを拡充していく方針です。

(2025年6月22日)
支払い手続きを終えると、自動的にリダイレクトされて、いわゆるThank youページが表示されますが、
これを再読み込みをすると、処理中などにステータスが遷移するバグを修正しました。

例えば、販売者側が発送を終えて”完了”に手動でステータスを変えたとします。

その時、購入者側が Thank you ページを再読み込みすると、ステータスが “完了” から “処理中” または”保留” に遷移します（どちらになるかは、管理ページの設定次第です）。

この時点でメールは発行されませんが、完了に戻すとメールが発行されてしまいます。

Thank youページが表示される前にその時点のステータスを確認するロジックを追加してバグを修正しました。

一定時間が経ったらThank you ページから他にリダイレクトし、かつ、戻れなくすることもあっても良いと思いますが、”一定時間”はどのくらいが適当か決めかねています。

(2025年6月3日)
推測ですが、PayPay側からのwebhook通知に間違った情報が含まれる場合がありそうです。
4月の初めにPayPayでwebhookにトラブルがあったと連絡を受けましたが、そのタイミングでPayPay4WCが誤作動を起こした可能性があります。これはユーザー様からのお問い合わせからの推測です。
そこで、現在のステータスと矛盾するwebhook通知は無視するように修正を加えました。
新バージョンは2.0.4fです。

(2025年3月4日)
2.0.4e
メモリの消費量を若干抑えることでわずかですが高速化しました

(2024年12月6日)
修正バージョン2.0.4d
[注文する]ボタン（あるいは [注文を確定する]ボタン )をクリックすると、PayPay のページが表示されますが、そのまま放置してしまうお客様がおられました。おそらく、ボタンをクリックした時点で決済が完了したと思われたのでしょう。

そこで、”注文する“ラベル を “PayPay のお支払いページに進む →”に書き替えて、手続きが残っていることをお伝えすることにしました。PayPayを選んだ時だけラベルが替わります。

このラベルを変更する方法
翻訳ファイル paypay4wc-ja.po を Poedit などで編集し、.mo ファイルを生成してください。
“クラシック購入手続き”を使っている場合はこれで変更されます。

Checkout Blocks を使っている場合は .mo ファイルは読み込まれず、JSON ファイルが必要です。

Checkout Blocks では、プラグイン実行時に .mo ファイルと同じフォルダにある paypay4wc-ja-wc-paypay4wc-payments-blocks.json を読み込んでいます。

このファイルは　”wp i18n make-json paypay4wc-ja.po –no-purge”というコマンドを使って生成した翻訳ファイルで、JSON ファイル形式です。元は、paypay4wc-ja-[md5].json というファイル名ですが、これをリネームしています。”wc-paypay4wc-payments-blocks” は、JSON ファイルを読み込む際に定義した handle です。

(2024年9月4日)
プラグインを検査するプラグインを導入してみたところ、修正箇所が見つかりましたのでアップデートしました(2.0.4c)

(2024年5月13日)
↓の件、修正バージョン2.0.4bをアップロードしました。
(2024年5月11日)
PayPayへ遷移後に、なんらかの理由で支払いが失敗した場合に、PayPay側ではエラーが表示されるものの、その後Woocommerceに戻った時にエラーがあった旨の表示が購入者側と管理者側の両方になされないバグを見つけました。

管理画面では「支払い待ち」の状態を維持していて、メッセージが記録されず、購入者がカゴに入れたまま放置している状態に見えます。
エラーがあったことがわかるようにしたいと思います。

(2024年4月18日)
2.0.4a2 Checkout Blocks使用時のロゴマークの大きさを調整。翻訳ファイルの修正

(2024年4月10日)
2.0.4a1をリリース。
未定義の変数が残っていましたので定義しました。
例外発生時のメモリ大量消費に対処するためログを出さない仕様に変更しました。

(2024年4月3日）
WordPressが6.5になったことで、Macのzipファイルがインストールできるようになりました。

例外発生時のメモリ大量消費問題については、Woocommerceを8.4にダウングレードしたところ、８万行に及ぶログが生成されていることがわかりました。

Woocommerceの最新版ではこれがメモリー大量消費のメッセージになったと推測します。
次期バージョンで例外発生時にログを出力しないことにします。PayPayとのやりとりは記録されます。

なお例外が発生したのは、あるユーザ様のサイトなのですが、原因はPayPayに伝えたIPアドレスが間違っていたことでした。

ロリポップではサイトのIPアドレスとサーバーのIPアドレスが異なるので注意が必要です。PayPayに伝えるのはサーバーのIPアドレスです。

(2024年4月2日）
「互換性のないアーカイブ」というメッセージが出てインストールできないと連絡がありました。

調べたところWordPress6.4.3ではMacのFinderで圧縮した.zipファイルが読み込めないとのことでした(えーっ!聞いてないよ! 　コマンドラインはOKです)

そこでWordPressからインストール可能な.zipファイルを作成してアップロードしました。

なお、以前のファイルでも、解凍後にアップロードするか解凍機能のあるftpソフトを使えばインストール可能です。

サイトとPayPayとの間の認証に問題が生じてQRコードが作れなかったときに

“Allowed memory size of 134217728 bytes exhausted”

というログが出力されることがあります。メモリを増やしても効果はありません。例外が発生したときにWoocommerceがうまく動作しないことが原因です。対応策を調査中です。

(2024年3月29日)
ご利用者様から本番環境でステータスが遷移しないというご連絡がありました。
こうしたご連絡は大変助かります。感謝しています。
修正したバージョン2.0.4をダウンロードできます。

(2024年2月26日)
Checkout Blocksが標準になる以前は問題にならなかったのですが、他の決済手段と干渉するケースがあったので対策しました。

(2024年2月19日)
Checkout Blocks利用時など処理が重い場合に、PayPayと通信ができない場合があります。

決済に進めずに終わる(process_payment()が起動しない）場合と、決済完了後に通信できない場合が考えられますが、前者はpendingのままにすれば購入者は他の決済手段を選べます。

後者は厄介で、通信できないために決済完了したかどうか確かめられません。

そこで、そのような可能性がある場合にPayPay for Business等で確認を促すノートを管理画面に残すことにしました。将来的には「要確認status」を作って遷移させて注意を促すことが考えられます。

(2024年1月31日)
修正を終えてリリースしました。
(2024月1月30日)

PayPay4WC-BC2.0.0としてリリースしました。

新バージョンに問題が見つかったのでしばらく公開をストップします。

当店自身は本プラグインの利用は未定です。

Checkout Blocksに対応していないプラグインを利用しているので、従来のまま運用します。（郵便番号自動入力が使えない。Stripeの日本語訳がひどい。送料計算プラグインがエラー表示を出すなど…)

[時間切れ問題]
Checkout Blocksの処理が重いので、有効化しているプラグインの数が多いとPayPayへの接続がうまくいきません。
これはJapanized for woocommerceがサポートするPaidyでも同様です。
おそらく他の決済プラグインも同様でしょう。
極力プラグインは減らしてください。

本プラグインでは何らかの原因でQRコードが生成されなかった場合、エラーメッセージを出してカートページに遷移します。
このときで余計なメールを出してしまう挙動への対応にとても時間がかかってしまいました。

なお、当店では送料を計算するプラグンがCheckout Blocksへの対応が不十分でそれが直るか、他の手段を見つけるまではCheckout Blocksに移行しません。

(2024月1月27日)
Checkout blocks対応：
[干渉問題]->[時間切れ問題]
干渉というよりCheckout Blocksでは今までよりも処理に時間がかって時間切れになってしまうことが原因のようです。プラグインの数が多いと誤動作します。
他の決済手段でも誤動作します。対策中ですが時間が必要です。

(2024月1月24日)
Checkout blocks対応：
[干渉問題]
現状では他のプラグインと干渉してPayPayサイトに遷移しないバグがあります。
当初Stripeを疑っていたのですが違いました。
Checkout Blocksと直接関係のないプラグインを有効にしても誤動作します。
今のところ特定のプラグインが原因ではないだろうと考えています

[webhook問題]
PayPayサイトに遷移した後に５分以上放置した場合、正常な動作では、webhookを使って情報のフィードバックがあるのですが、Checkout Blocksの環境ではその情報を受け取れずThank youページに移ってしまい注文受付完了となってしまうバグがあります。

ステータス自体はPendingのまま動かないことを利用してカートページにリダイレクトさせ、ステータスをFailedに遷移させることにしました。

公開については未定です。あえてCheckout Blocksを使う理由が今のところないのが大きな理由ですが、他の配送設定のプラグインにバグがあったり、Stripeにも変なところがあったりして、全体としてまだ使用に堪える状態ではないからです。

試してみたい方はご連絡いただければダウンロードできるようにします。

(2024年1月17日)
さあ本番環境でテスト！と思ったら動きません。Dockerを使ったテスト環境では正常に動作するのですが、本番環境では動きません。調査中ですが長引きそうです….。Checkout Blocksを使わない従来の設定に戻すと動きます。

(2024年1月5日)
Checkout blocks対応はほぼ開発を終えました。残っているのはiconの表示設定の部分です。今月中にはリリースしたいと考えています。

(2023年12月17日)
Checkout blocksには未対応です。従来のショートコードを使った購入ページを使ってください。開発中ですが、すぐには対応できません。Japanized for WooCommerceの対応もかなり先になるそうですが、その前に終えたいと思っています。

(2023年11月25日）

一時的にダウンロードできなくなっていましたが、現在は復旧しています。

(2023年11月17日)

稀なことですが、PayPay側で決済処理が進んでpaymentidが採番されたにも関わらず、エラーとなることがありました。PayPay側で「支払いできませんでした。エラーが発生しました」というメッセージが表示されます。
paymentidがあれば決済(or与信)完了と思っていましたが、決済前に採番する仕様なのでしょう。幸いFAILEDというステータスを返してきますので、それを利用してwoocommerce側でステータスを”pending”とする処理を加えました。
アップデートをお勧めします。

(2023年10月13日)
Woocommerce8.2.0でのチェックは済んでいます。1.4.5aに変更しました。変更点は２つ。

1)「与信（出荷売上)」設定時にon-holdからprocessingを経ずに直接completedに変更した場合に、直後にprocessingに戻されてしまう不具合を修正しました。
これにより、メールが重複して発行されることがなくなりました。

2)与信中（on-hold）に部分的な金額の取り消しの必要が生じても、PayPayアプリは最初にブロックした金額をon-hold中は減らせないということがわかりました。PayPayアプリの仕様の問題なのでこちらではなんともできないです。

completedに遷移した時点で正しい金額で精算されます。

paypay4wcはこの辺を考慮しておらず不要なメッセージを管理画面に出力していたので修正しました。

いずれも「即時売上」の場合は関係ありません。

(2023年8月10日)
WoocomerceのHPOSへの強制変更は8.0からの予定でしたが、10月の8.2まで延期だそうです。

paypay4wc1.4.5はHPOSに対応しています。8.2.0-rc.2でチェックしています。7.9でも使えます。

(paypay4wc1.4.4dはHPOSに対応していませんので10月以降、その動作は不明です)

(2023年8月9日)

—>下記の件、やはりPayPay側に問題がありました。現在は正常に戻っています。

PCを使ったテスト環境で、PayPayに遷移した後のページの右側のブロックが表示されません。ブルーの枠で囲まれたログイン用のブロックが表示されるべきです。

本番環境では正常に表示されます。

paypay4wcのバージョンとは関係なく、1.4.4dでも1.4.5でも同じ現象です。

paypayに遷移した後のことなので、paypay側に仕様変更があったのだと推測します。昨日までは正常に表示されていました。現在PayPayに照会中です。

(2023年8月2日)

WooCommerce8.0対応版の1.4.5をリリースしました。

WooCommerce 8.0は 8月8日にリリース予定です。データベースの変更を伴う大幅なアップデートです。

1.4.5より古いバージョンは、このWooCommerce8.0に対応していません。

もしWooCommerceを”自動更新”に設定していた場合は手動に切り替えたほうが良いと思います。
paypay4wc以外にも対応が必要なプラグインがたくさんあるはずです。

対応が必要なプラグインを調べるには、

woocommerce->”設定”->”高度な設定”->”機能”のページを開いて、”高パフォーマンス注文ストレージ (COT)”にチェックを入れて[変更を保存]します。

(2023年4月25日)
「出荷売上」の場合、PayPay for Businessの”サマリー”には取引が表示されません。どれだけ取引があっても０円という仕様だそうです。「取引」を選んで「期間」等を選ばない限り確認できません。サマリーで確認できるのは店頭売上や、即時売上だそうです。使いにくいですね。

(2023年3月18日)

本プラグインの設定画面ではwebhook用のURLの<一部>を自由に設定できます。入力欄の下ではデフォルトのURL<全体>を表示していますが、入力できるのは末尾の/で挟まれた部分だけです。https〜と先頭から入力するのは間違いです。

(2023年2月28日)
課金モデル「出荷売上＆即時売上」の審査が通りました(いままでは「即時売上」で運用していました）。

ウェブペイメントの場合、課金モデルは次の３択です。
「即時売上」（注文確定と同時に与信と支払いが行われる）
「出荷売上」（注文時は与信のみ行い、出荷時など店側で操作後に支払いが行われる）
「即時＆出荷売上」(どちらかを店側で設定できる）
これらは申請後に変更ができません。変更には最初から審査のやり直すしかありません。IDも全て新しいものになります。選択肢など用意せずPayPalやStripeのように「即時＆出荷売上」だけで良いんじゃないかと思うのですがねえ。

なお、余談ですが海外からのアクセスを禁止していると審査の手間と時間が増えます。

(2023年2月12日)
PayPayの用語に合わせるため、管理画面上でラベル「与信」を「即時売上or出荷売上」に変更しました。その右横のプルダウンメニューも「与信」を「与信（出荷売上）」に変更しました。最新バージョンは1.4.4c1です。機能上の変更はありません。

(2023年1月31日)
「与信」にセットするとQRコードが生成できませんでした。テスト環境は問題ありません。本番環境だけです。原因は、本申請時に「課金モデル」：「即時売上＆出荷売上」を申請していなかったためです。
申請するには新たなアカウントを取り直す必要あるとのことでした。あらたなアカウントとは、メールアドレスも新しく用意して審査を受けるということです….

(2023年1月18日)
半年ほど何もしていませんが、1.4.4cが現行バージョンです。今のところ仕様の変更や機能追加の予定はありません。もしSDKがアップデートされたら、それに合わせて本プラグインもアップデートします。

(2022年6月22日)
バージョン1.4.4cをリリースしました。SDKが2.07にアップデートされたことによるものです。これはGuzzlehttpのバグ修正版です。

(2022年6月16日)
バージョン1.4.4bをリリースしました。
SDK2.06にアップデートしました。Guzzlehttpが脆弱性authorization leakage bug during HTTP downgradeに対応してアップデートされたことによります。

(2022年6月6日)
バージョン1.4.4aをリリースしました。
GuzzleにCross-domain cookie leakageと呼ばれる脆弱性が見つかってアップデートされた関係で、SDKも2.05にアップデートされました。それに伴って本プラグインもアップデートしました。Guzzleのデフォルトの設定では問題は生じないとのことですので、paypay4wc1.4.4でも問題ありません。

(2022年6月1日)
オンラインでの「あと払い」については6月27日より利用可能になりますが、プラグインについてはそのままお使いいただけます。readme.txtについてはのちのバージョンアップで対応します。

(2022年5月20日)
ライブラリの名前空間を変更することにより他のプラグインとの競合を避けるようにしました。最新バージョンは1.4.4です。

(2022年5月19日)
Guzzlehttpのバージョンの違いで、他のプラグインと競合してしまい、動かない現象がありました。該当するプラグインのGuzzlehttpを最新バージョンにすれば解消すると思われます。または、一時的に該当のプラグインを削除して再びインストールすると解消するかも知れません。根本的な解決については次期バージョンアップで対応したいと思います。

なお、以下のようなログが生成されます。Guzzlehttpを通じてAPIキーによる認証が行われていますので、動かない時はそのようなプラグインをお調べください。

CRITICAL Uncaught Error: Call to undefined method GuzzleHttp\Utils::chooseHandler() in /****/wp-content/plugins/paypay4wc/vendor/guzzlehttp/guzzle/src/functions.php:61

(2022年5月6日 5月9日追記)先月末あたりからテスト環境の決済ページでホワイトアウトする現象が見られますが本番環境では問題ありません。本プラグインが原因ではないと思います。PayPayにて調査中です。–>(5月9日)解消されました。これを書いている時点で何のアナウンスもありませんが、PayPayからメールが届いて解消されたとのこと。こちらでも確認しました。

(2022年4月29日 5月2日追記、5月4日修正)
「詳細」に商品名等を表示するようにしています。たくさんの種類を同時に購入するとエラーとなってしまうので修正中です。–>修正しました。

追記：
修正バージョンをリリースしました。1.4.3aです（最新は1.4.3b)。
1.4.3aより前のバージョンは表示文字数が概ね85文字を越えるとエラーとなってPayPayのページに遷移しません。さらに1.4.3bからSDK2.04に対応しました。1.4.3bは不要な記述が削られただけで1.4.3aとほとんど差がありません。

(2022年3月12日 4月1日追記)
ロリポップなどの一部のレンタルサーバーでは、ホームページ等に割り当てられたIPアドレスと、外部のAPI(PayPay等)との接続IPアドレスが異なります。そしてPayPayに伝える必要があるのはこの接続IPです。

加盟店ID、Key 、シークレットが正しくセットされているにもかかわらず認証できない場合は、このIPアドレスをお調べください。

例えば、m123.rentalserver.jpを借りて、www.myshop.co.jpというホームページを作った場合、それぞれに割り当てられたIPが異なる場合があります。

www.myshop.co.jp -> AAA.BBB.CC.DD（ホームページ等のIP)
m123.rentalserver.jp -> eee.fff.ggg.hh (レンタルサーバーのIP=APIとの接続IP)

伝えるべきは、eee.fff.ggg.hh です。

本番環境では間違ったIPをPayPayに伝えた場合、PayPayの決済ページに遷移しません。その場合、次のようなログ(woocommerce->ステータス->ログ)が出力されます。

2022-03-01T10:11:31+00:00 DEBUG PayPay\OpenPaymentAPI\Controller\ClientControllerException Object
(
[resultInfo:PayPay\OpenPaymentAPI\Controller\ClientControllerException:private] => Array (

            [code] => UNAUTHORIZED

            [message] => Unauthorized request

            [codeId] => 08100016

        )
（おまけ）ロリポップの場合は次のコマンドで調べられます。”hoge”は適当に置き換えてください。

nslookup ftp.hoge.lolipop.jp

ただし、ロリポップでは今後メンテナンス等によりIPは変更される場合があるのだそうです。
ちなみに当店のサーバーはロリポップではありません。

(2022年3月1日)
現在、ユーザー様からGoogle Listings & Adsとコンフリクトするとの連絡を受けています。—–>Google Listings & Adsを再インストールしたところエラーが無くなり解決したそうです。

(2022年2月26日)
ヘッダー部分の記述ミスを修正しました。なお、このバージョンからphp7.4以上が必要です(php8 OK)。(ver1.4.2b)

(2022年2月25日)
Guzzle等のライブラリを更新しました。これによりGoogle Listings & Adsに関わるエラーは解消しています。(ver1.4.2a)

(2022年2月23日)
ver1.4.1にwebhookが動作しないバグがありましたので修正しました。
(ver1.4.2)

(2022年2月10日）
Webhook用URLの一部を管理画面から自由に変更できるようにしました。
（ver1.4.1)

(2022年2月８日）

複数回返金機能を追加しました。２０２１年５月２０日までに審査が通った加盟店に限り、PayPayに申請して事前設定が必要です。加盟店ID(テスト環境と本番用の２つ）を伝えます。
２０回まで返金できる仕様のはずですが、なぜか２１回できました。２２回目は出来ませんでした。Woocomerceの管理画面上は２２回目も成功した様に表示されるますが、Sandboxの取引一覧には反映されませんでした。
なお翻訳ファイルの一部に修正があります。
(ver1.4)

(2022年1月26日)
PayPayからアナウンスのあった「複数回返金機能」については、このプラグインは現バージョンでは対応していません。Woocommerce管理画面上では可能ですが、実際は最初の返金が処理されるだけです。プラグインにこの機能を実現するのは簡単だと思うのですが、確定申告が済むまで手をつけられません…

(2022年1月11日)
テストユーザのPayPay残高を表示する手前でエラーになったりならなかったりします。Sandboxに割り当てられた計算リソースが貧弱なのでしょう。開発、検証が進まず困ったことです。

(2022年1月7日)
下に書いた不具合は解消されました。詳しい理由は知らされていませんが、本プラグインの問題ではなくPayPay側の設定の問題だったようです。

(12月28日)
テスト環境で不具合が生じていて、テストができない状態にあります。PayPayへのログインに失敗します。SDKを2.02にアップデートしても解消されませんでした。本番環境ではログインできて決済に支障はありません。現在サポートに連絡して回答待ちです。

(5月12日追記 15日修正)
大きなバグがあったので修正しました。
PayPay決済画面に移ってそのまま放置すると５分で支払不能になるのですが、そのままにしておくとThankyouページにリダイレクトし、さらに注文受付メールが購入しなかった人に届き、管理画面上は支払い済みになって「処理中」ステータスになります。

このままでは店舗側からは注文が来たと思って発送してしまいます。これは決済できないのにstatusがCREATED(QRコード発行済)のまま変わらないPayPayのAPIに問題がありそうです(仕様だそうです）。時間切れに相当するstatusが用意されていません。（EXPIRED：残高ブロック期限切れ はあるのですが…)
実は当然のことながらこの条件下ではpaymentIDは発行されないので、これを元にエラー処理をすることにしました。

他にも下記の不具合を直したものを作りました。ダウンロードできます。完全無料です。

もちろん、本番で使用実績があります。「本番用に使いたかったらキーコードを買ってください」なんてことはありません。ただし、当店は何があっても一切責任は負わないということをご了解ください。あなたのものはみんなのものというGPLライセンスなので配布も改変も自由です。

https://www.mamekichi-an.com/product/paypay4wc/