自サイトにJPYC決済を「送金」を使って簡易的に導入してみるの回
前回のアプリ導入の続き。本来の目的である自サイトに、JPYCで支払いを受け付ける最小構成のページを実際に作って、着金確認まで通した記録。
2026年6月時点の検証。仕様は変わりうるので、導入時は公式の最新情報も併せて確認お願いします。
また、この商品は実装していますが何の商品も無いので購入はしないでね、約束だよ。
今回のゴール、目指すこと
最初に、何を目指して何を目指さないかをはっきりさせておきます。
目指すこと：「サイトでQR・受取アドレスを表示 → 購入者がJPYCを送る → 着金を確認する」という、最小構成の決済フローを自分のサイトで通すこと。
今回あえてやらないこと：スマートコントラクトの作り込み、ガスレス決済、金額の自動入力。本来理想形だと思いますが、最初から盛り込むと確実に動くところまで辿り着けない気がするという事で。
まずは枯れた手段で、確実に着金確認まで通すことを優先。
この割り切りが、結果的に「個人でも1日で導入できる」現実的なラインかなと思う次第。
仕組みの全体像
今回作ったものは、いたってシンプル。
サイトに受取アドレスとQRコードを表示する
購入者が自分のウォレットからJPYCを送金する
購入者が報告フォームに「名前・メール・購入商品・送金時のトランザクションハッシュ」を入力して送信する
自分宛に通知メールが届く
メール内のリンクからブロックチェーン上で着金を目視確認する
確認できたら商品を渡す
ポイントは、お金の流れ（ブロックチェーン）と注文情報（フォーム）を分けているところ。
JPYCでの送金は「誰から誰へ、いくら」しか記録しないみたいなので、「誰のどの注文か」はフォームの自己申告で補う、という構成にしました。
データベースも使わず、通知はメールだけ。最小構成だからこそ、簡単に実装できたんじゃないかな。欲張らない。
ページの中身
作ったファイルは2つ。
`index.php` … 商品・金額・受取アドレス・QRコード・送金手順・報告フォームを表示するページ
`send-form.php` … フォームの送信を受け取り、通知メールを送る処理
PHPが動くサーバーがあれば設置できます。
今回はサイトに `/jpyc-pay/` というディレクトリを作り、この2ファイルを設置。
現物はこちら https://mahanafactory.com/jpyc-pay/
（冒頭にも書いた通り、中身はテスト用で実際の商品はありません。購入はしないでね。）
表示ページ（index.php）でやっていること
ページは4つのステップで構成しました。
商品・金額の確認
送金先アドレス（アドレス文字列とQRコードを表示。タップでコピーできる）
送金の手順（ウォレットで何をすればいいかの案内）
送金報告フォーム（名前・メール・購入商品・トランザクションハッシュを入力）
QRコードは、JavaScriptのライブラリで受取アドレスから自動生成、できるだけ手を抜く。
受取アドレスを1か所書き換えれば、表示・コピー・QRのすべてに反映されるように。
送信処理（send-form.php）でやっていること
フォームが送信されると、入力内容を検証して、自分宛に通知メールを送信。
地味だけど、最低限の安全対策は入れておく。
CSRFトークン（外部から勝手にフォームを送られるのを防ぐ）
ハニーポット（botが自動入力する隠しフィールドで、機械的な送信を弾く）
入力値の検証（メール形式のチェック、文字数制限など）
通知メールには、Polygonscan（ブロックチェーンの取引を見られるサイト）で該当の送金を確認できるリンクを自動生成するように。着金確認とかいるよね、いずれ多分。そう思うので。
つまずきポイント：ここが一番ハマった
実際にやってみて、想定外だったことや判断が必要だった点を残しておく。
もし試すのであれば参考にしてもらえれば。
つまずき①：受取ウォレットは「コントラクトアドレス」で大丈夫なのか
受取に使う HashPort Wallet のアドレスは「コントラクトアドレス」という種類。
前回、取引所から送金しようとしてコントラクトアドレス宛だと弾かれた経験があったから、「サイトの受取に使って平気なのか?」が不安なポイント。
結論から言うと、購入者がウォレットから送る分には問題なさそう。（ごめん正直自信ないです） 弾かれるのは取引所から直接送る場合で、ウォレット同士の送金は通る。
実際に MetaMask から HashPort のアドレスへ送って、ちゃんと着金は確認済み。
念のため、購入者への案内には「取引所から直接ではなく、ご自身のウォレットから送金してください」と添えておくのが安全な気がする。
つまずき②：HashPortの「支払う」では、このQRは読めない
ここが今回いちばんの発見かも、実装に入ってから初めて理解した。
着金テストのとき、HashPortアプリで自分のサイトのQRを「支払う」メニューから読み取ろうとしたら、こんなエラーが表示。
「このQRコードでは支払えません。支払い用QRコードをご確認ください」
アドレスの種類（コントラクト）の問題かと思ったんだけど、どうもなんか違うような。
同じQRを「送金」メニューで読むと、アドレスが正しく入るのを見たので。
調べてみると、HashPortの「支払う」は、HashPortが店舗向けに発行する専用の決済用QRしか受け付けない仕組み。
自分のサイトが出している「アドレスをエンコードしただけのQR」は、その専用フォーマットではないので弾かれる、というわけで。
今回の重要な教訓：購入者には「支払う」ではなく「送金」メニューを使ってもらう。 この仕組みの場合、案内に明記しないと、同じところでつまずくよなぁと反省。ちゃんと調べてからやらないと駄目ね。
実際に通してみる：フォーム送信から着金確認まで
ここからは、実際に10 JPYCのテスト送金を、頭から最後まで通した記録。
商品は検証用に「サイトサポート（テスト）10 JPYC」というものを1つだけ用意。
ステップ1：送金する
MetaMask から、サイトに表示された HashPort の受取アドレスへ、Polygonネットワークで10 JPYCを送金。
前回確認した通り、ガス代は1円未満、着金は数秒という結果。
ステップ2：報告フォームを送信する
送金が終わったら、サイトの報告フォームに必要事項を入力して送信。
トランザクションハッシュ（送金時にウォレットに表示される「0x」で始まる長い文字列）も貼り付け。
ステップ3：通知メールを受け取る
送信すると、自分宛に通知メールが無事届きました。
名前・メール・購入商品・トランザクションハッシュ・送信日時が整形されて入っていて、Polygonscanで確認できるリンクも自動で付いていて一安心。
========================================
JPYC 送金報告（新着）
========================================
購入商品:
サイトサポート（テスト）（10 JPYC）
トランザクションハッシュ:
0x8e9e637f...（省略）
Polygonscanで確認:
https://polygonscan.com/tx/0x8e9e637f...
送信日時:
2026-06-27 14:02:06
========================================（実際のメールにはお名前・メールアドレスも入るように、ここでは省略）
ステップ4：ブロックチェーン上で着金を確認
フォームはあくまで自己申告なので、本当に着金しているかを自分の目で確認大事。
確認したのは次の5点。
ステータスが成功（Success / 完了）か
金額が注文と一致するか（今回は10 JPYC）
送金先が自分の受取アドレスか
正規のJPYCトークンか（偽トークンでないか）
取引が確定しているか（「送信済み」ではなく「確定」）
この5点を、2か所で確認できました。
ひとつは Polygonscan。
10 JPYCが正規のJPYCトークンで、自分の受取アドレスに、成功ステータスで届いていることが確認する。
もひとつが HashPortアプリの取引履歴。
こっちでは「受取・10 JPYC・完了」と一目で分かる表示で、初心者としてはこっちの方が安心感あるよね。
この5点が一致していれば、安心して「入金済み」と判断できるかな。
これで、フォーム送信から着金確認までの一連が、実際に通ったといえそう。
簡易実装テストとしてはオッケーではなかろうか。
やってみて分かった、向き・不向き
正直なところ、今回の設置方法で本気で使うのは個人的にはおすすめできないなぁ。
やってもいいケースとしては
まず仕組みを理解したい人
手数料ゼロでキャッシュレスを試したい個人
この方法ではやらない方がいいと思ったところ
まず常識的に複数注文さばくの大変よね（手動確認が追いつかないような）
金額が自動で入らないので、購入者が手入力する手間がある、面倒
トランザクションハッシュが自己申告なので、着金の目視確認を省けないよね
購入者がJPYCとウォレットを持っている必要がある
特に「金額が手入力」「着金は手動確認」の2点は、件数が増えると地獄。
今回はそこを人の手でカバーできる規模だからこそ成立するような。
次はもっと本格的にできるか
今回は「送金」で確実に通すところまで。
でも、もっと購入者にやさしい形が2つ、視界に入っています。次はここに踏み込んでみようかな。
候補1：HashPortの「支払う」(for Biz) は個人でも使えるのか
今回エラーで弾かれた「支払う」メニュー。
HashPort が店舗向けに提供している決済機能で、専用QRを使うと金額が自動で入り、しかもガス代が無料になりるようだ。購入者の手間とミスが激減するまさに理想形。
ただ「ビジネスウォレット登録」が必要で、個人の少額販売でこれが使えるのか、登録に事業者要件があるのかは未確認です。
今度はここを実際に調べて、使えるなら導入してみようかと。
候補2：EIP-681 という標準規格のQRなら金額まで入るのか
もうひとつ、「支払う」専用機能に頼らず、EIP-681という標準規格のQRを使う道もあるという情報。
これは `ethereum:（コントラクト）@137/transfer?...` という形式で、対応ウォレットなら読み取り時に金額・チェーンが自動入力されると。本当?
これができれば「自前実装で理想形に近づける」という形になるんよね。
ただ、ウォレットによって正しく解釈されるかわかんないので、これは実機での検証が必須だなと。
次は、この「支払う」と「EIP-681」の2つを実際に試して、自分のサイトの決済をどこまで楽にできるかを検証。 「送金で確実に」から「支払うでスマートに」はできるのか。
まとめ
自分のサイトに、JPYCの受取アドレス・QR・報告フォームを置くだけで、最小構成の決済は導入
お金の流れ（ブロックチェーン）と注文情報（フォーム）を分けた方がいいよね
受取がコントラクトアドレスでも、購入者がウォレットから送れば問題ないのはわかった
HashPortでは「支払う」ではなく「送金」を使ってもらうというかこれしかなかった
着金は必ず確認する（成功・金額・送金先・正規トークン・確定）
少人数・少額なら、人の手でまわせる
決して派手ではないけれど、「動く決済を自分のサイトに持てた」という手応えはあった。
次はもっと洗練させていきたいですねぇ。