A guide to simply introducing JPYC payments to your own site using "transfers"

The goal for this time, what I am aiming for

First, I will clarify what I am aiming for and what I am not.

What I am aiming for: To complete a minimal payment flow on my own site: "Display QR code/receiving address on the site -> Purchaser sends JPYC -> Confirm receipt of funds".

What I am intentionally not doing this time: Smart contract development, gasless payments, and automatic amount entry. While I think these are ideal, I feel that if I include them from the start, I won't be able to reach the point where it definitely works.
First, I am prioritizing using proven methods to reliably confirm the receipt of funds.

I think this trade-off is a realistic line that allows even an individual to implement it in a day.

Overview of the mechanism

What I made this time is quite simple.

• Display the receiving address and QR code on the site

• The purchaser sends JPYC from their own wallet

• The purchaser enters their "name, email, purchased product, and transaction hash at the time of transfer" into the report form and submits it

• A notification email arrives for me

• Visually confirm the receipt of funds on the blockchain via the link in the email

• Deliver the product once confirmed

The point is that the flow of money (blockchain) and order information (form) are separated.
Since JPYC transfers only seem to record "who sent to whom and how much," I configured it so that "whose order it is" is supplemented by the purchaser's self-report in the form.
I didn't even use a database, and notifications are only by email. I think it was easy to implement precisely because it is a minimal configuration. Don't be greedy.

Contents of the page

I created two files.

• `index.php` ... A page that displays the product, amount, receiving address, QR code, transfer instructions, and report form

• `send-form.php` ... A process that receives the form submission and sends a notification email

You can set this up if you have a server that runs PHP.
This time, I created a directory called `/jpyc-pay/` on the site and placed these two files there.

See the actual site here https://mahanafactory.com/jpyc-pay/
(As written at the beginning, the content is for testing purposes and there are no actual products. Please do not make any purchases.)

What is done on the display page (index.php)

The page is composed of four steps.

1. Confirmation of product and amount

2. Transfer address (Displays the address string and QR code. Can be copied by tapping)

3. Transfer procedure (Instructions on what to do in your wallet)

4. Transfer report form (Enter name, email, purchased product, and transaction hash)

The QR code is automatically generated from the receiving address using a JavaScript library, keeping it as simple as possible.
By rewriting the receiving address in one place, it is reflected in the display, copy function, and QR code.

What is done in the submission process (send-form.php)

When the form is submitted, the input content is verified and a notification email is sent to me.
It's modest, but I've included minimal security measures.

• CSRF token (Prevents forms from being sent arbitrarily from the outside)

• Honeypot (A hidden field that bots automatically fill in, blocking mechanical submissions)

• Input validation (Email format check, character count limits, etc.)

The notification email is set to automatically generate a link that allows you to check the relevant transfer on Polygonscan (a site where you can view blockchain transactions). I think I'll probably need to confirm receipt eventually, so I'm doing this.

Stumbling blocks: This is where I got stuck the most

I'll leave behind the unexpected things and points that required judgment after actually trying it.
Please use this as a reference if you decide to try it yourself.

Stumbling block 1: Is it okay to use a "contract address" as the receiving wallet?

The address for the HashPort Wallet used for receiving is a type called a "contract address."
Last time, I had an experience where a transfer from an exchange was rejected because it was addressed to a contract address, so I was worried about whether it was okay to use it for receiving on a site.

To conclude, it seems there is no problem as long as the purchaser sends it from their own wallet. (Sorry, I'm honestly not confident about this.) It only gets rejected when sending directly from an exchange; transfers between wallets go through.
I have actually confirmed receipt by sending from MetaMask to the HashPort address.

Just to be safe, I feel it's safer to add a note to the instructions for the purchaser saying, "Please send from your own wallet, not directly from an exchange."

Stumbling block 2: The HashPort "Pay" feature cannot read this QR code

This might be the biggest discovery this time; I only understood it after I started the implementation.

During the deposit test, when I tried to scan my site's QR code using the "Pay" menu in the HashPort app, this error appeared.

I thought it was an issue with the address type (contract), but it seemed like something else. Because I saw that
the address is entered correctly when reading the same QR code with the "Send" menu.

Looking into it, the HashPort "Pay" feature is designed to only accept dedicated payment QR codes issued by HashPort for merchants. The "QR code that just encodes the address" displayed by my site is not in that proprietary format, so it gets rejected.

Important lesson learned: Have purchasers use the "Send" menu, not "Pay". With this setup, I realized that if I don't explicitly state this in the instructions, users will stumble at the same place. I really need to research things properly before doing them.

Running a real test: From form submission to deposit confirmation

From here on, this is a record of running a 10 JPYC test transfer from start to finish. I prepared one item for verification called "Site Support (Test) 10 JPYC".

Step 1: Send the funds

From MetaMask, I sent 10 JPYC on the Polygon network to the HashPort receiving address displayed on the site. As confirmed last time, the gas fee was less than 1 yen, and the deposit arrived in a few seconds.

Step 2: Submit the report form

Once the transfer was complete, I entered the necessary information into the site's report form and submitted it. I also pasted the transaction hash (the long string starting with "0x" that appears in the wallet during a transfer).

Step 3: Receive the notification email

Upon submission, the notification email arrived safely. It contained the formatted name, email, purchased item, transaction hash, and submission date, and it even automatically included a link to check on Polygonscan, which was a relief.

========================================
  JPYC 送金報告（新着）
========================================

購入商品:
  サイトサポート（テスト）（10 JPYC）

トランザクションハッシュ:
  0x8e9e637f...（省略）

Polygonscanで確認:
  https://polygonscan.com/tx/0x8e9e637f...

送信日時:
  2026-06-27 14:02:06
========================================

(I have omitted the name and email address here, but they are included in the actual email.)

Step 4: Confirm the deposit on the blockchain

Since the form is just a self-report, it is important to verify with my own eyes that the funds have actually arrived. I checked the following five points.

• Is the status Success (Completed)?

• Does the amount match the order? (10 JPYC in this case)

• Is the destination address your own receiving address?

• Is it a legitimate JPYC token?(Is it not a fake token?)

• Is the transaction confirmed?(Confirmed, not just "sent")

I was able to verify these 5 points in two places.

One is Polygonscan.
Verify that 10 JPYC is a legitimate JPYC token, that it reached your receiving address, and that the status is successful.

The other is the HashPort app transaction history.
Here, it's displayed at a glance as "Received, 10 JPYC, Completed," which is more reassuring for beginners.

If these 5 points match, I think you can safely judge it as "payment received."
With this, it can be said that the entire process from form submission to payment confirmation has actually worked.
I think this is fine as a simple implementation test.

What I learned about the pros and cons

Honestly, I wouldn't personally recommend using this setup method for serious business.

Cases where it might be okay to do it:

• People who want to understand the mechanism first

• Individuals who want to try cashless payments with zero fees

Points where I thought it's better not to use this method:

• First of all, it's obviously hard to handle multiple orders (manual confirmation can't keep up)

• Since the amount isn't entered automatically, the buyer has to enter it manually, which is a hassle

• Since the transaction hash is self-reported, you can't skip visual confirmation of the payment

• The buyer needs to have JPYC and a wallet

In particular, the two points of "manual amount entry" and "manual payment confirmation" become a nightmare as the number of transactions increases.
This time, it only works because it's on a scale that can be covered by human effort.

Can I do it more professionally next time?

This time, I've managed to get it working reliably using "transfers."
However, I have two more user-friendly forms in sight. I think I'll try diving into those next.

Candidate 1: Can individuals use HashPort's "Pay" (for Biz)?

The "Pay" menu that was blocked by an error this time.
It is a payment feature provided by HashPort for merchants, and using a dedicated QR code automatically enters the amount and even makes the gas fee free It seems to be the ideal form that drastically reduces the effort and mistakes of the purchaser.

However, "Business Wallet Registration" is required, and I haven't confirmed if this can be used for small-scale individual sales or if there are business requirements for registration.
I'm thinking of actually looking into this next, and if it can be used, I'll try to implement it.

Candidate 2: Can a standard EIP-681 QR code also include the amount?

Another piece of information is that there is a way to use a standard EIP-681 QR code without relying on the dedicated "Pay" feature.
This is in the format `ethereum:(contract)@137/transfer?...`, and it is said that compatible wallets will automatically enter the amount and chain when scanned. Is that true?

If I can do this, it will be a form of "getting closer to the ideal with my own implementation."
However, since I don't know if it will be interpreted correctly by all wallets, I think verification on actual devices is essential.

Next, I will actually test these two, "Pay" and "EIP-681," to verify how much I can simplify payments on my own site. Can I go from "reliably via transfer" to "smartly via pay"?

Summary

• A minimum viable payment system can be implemented just by placing a JPYC receiving address, QR code, and reporting form on your own site

• It's better to separate the flow of money (blockchain) and order information (form)

• I learned that even if the recipient is a contract address, there is no problem as long as the purchaser sends it from their wallet

• With HashPort, I had to have them use "transfer" instead of "Pay," or rather, that was all there was

• Always confirm receipt of funds (success, amount, destination, valid token, confirmation)

• For small numbers of people and small amounts, it can be handled manually

It's by no means flashy, but I felt a sense of accomplishment in "having a working payment system on my own site."
I want to refine it further next time.