Standardizing receipts and refunds for WalletConnect Pay

Ideas
1

Hey everyone. I want to throw out an idea that I think could be genuinely useful for the ecosystem. I am not trying to claim ownership of this or build it myself. I just want to share it so the right teams can run with it if it resonates.

This is not meant as a WalletConnect Network or governance change. It is a lightweight standard that wallets, PSPs, and merchants could implement on top of WalletConnect Pay. If it works well in a pilot, it could always be formalized later.

Right now, stablecoin payments are getting easier, but the experience still often ends at “transaction sent”.

In real commerce, what makes payments feel real is what happens after the payment. You need a receipt you can find later. You need refunds or returns that do not become a manual support mess. And you need a safe way to contact the merchant without falling for fake support.

Idea: “ReceiptConnect”. A small, wallet agnostic standard for receipts and refunds on top of WalletConnect Pay.

What it could look like.

1. Receipts that wallets can store and show After a WalletConnect Pay payment succeeds, the merchant or PSP sends a receipt payload to the wallet. The receipt is signed so the wallet can verify it. The wallet stores it locally and shows it in a simple receipts view.

A simple v1 receipt would probably be enough with:

  • Merchant identity, ideally something the wallet can verify, like a verified domain or app identity.
  • Payment reference, like a tx hash or intent reference.
  • Amount, asset, chain. Timestamp. Optional line items, plus a short policy summary like “refunds within 14 days”.

2. A refund flow that works across wallets and merchants From the receipt, the user taps “Request refund”. The wallet sends a standardized refund request to the merchant or PSP, and the merchant responds with status updates.

A minimal status flow could be:

received

under_review

approved or rejected

refunded, with tx reference

This removes a lot of friction. Wallets do not need custom refund logic per merchant, and merchants do not need to support different refund flows for every wallet.

3. Verified support channel Tie the receipt to verified merchant identity, and only show “Contact support” when it is actually verified. That feels like an easy win to reduce fake support scams, and it also makes receipts more trustworthy.

Who could implement this Wallet?

Teams could add the receipts view and message handling. PSPs or merchants could issue receipts and handle refund requests. A third party builder could publish a reference schema, test vectors, and a demo integration others can copy.

What I am not trying to solve here Chargebacks or arbitration. Legal invoicing rules per country. On chain storage of receipts by default. Privacy first should be the default, with an option to export if the user wants.

Possible simple starting point Keep v1 minimal and get one wallet plus one PSP plus a demo merchant working end to end. Add a capability flag so wallets and merchants can mark themselves as “ReceiptConnect compatible”. Iterate later with optional extensions, like loyalty points or richer invoice fields.

Questions for feedback:

1. What is the minimum receipt payload that is still useful for real support and refunds?

2. Who should be allowed to sign the receipt in v1, merchant only, or merchant and PSP with clear attribution?

3. Should v1 refunds be full refunds only, to keep the first version simple?

4. Any wallet teams, PSPs, or merchants willing to pilot this, and what would block you from doing it?

5 Likes
2

It is a good idea to have this. My question is whether it falls under WCT or on the wallet who should build this function or on the merchant’s POS terminal?

At the same time, I’d like to add: who will pay for the gas fee for the returned leg or refund?

2 Likes
3

Good questions. I do not see this as something WalletConnect itself would “build”, since WC is the connection layer. It would likely be split like this.

Wallets implement the UX, store and show receipts, and expose a “Request refund” action.

Merchants or PSPs behind the POS issue the receipt after payment, and handle refund requests and status updates. The POS can show it, but the logic lives in the merchant backend or PSP.

If WalletConnect wanted to support it without changing the network, it could stay lightweight, publish a small spec for payloads, recommend message method names, and add a capability flag so wallets know the merchant side supports it. A pilot could start like that.

If changing the network is on the table later, a bigger option could be making it an official WC extension, and possibly adding a standardized receipt retrieval or mailbox style primitive so receipts can be recovered across devices, still end to end encrypted.

On gas for refunds, a few workable models. Merchant or PSP pays gas and sends the refund, best UX. Refund on the same chain and asset as the original payment, predictable fees. If user pays gas, disclose it up front with an estimate, or refund net of fee with clear disclosure. For small amounts, store credit avoids on chain gas entirely.

1 Like