EERC‑681
SpecAdoptionIn‑personBuilderResources

In‑person payments

ERC‑681’s most compelling UX is physical-world payments: a static QR code or NFC tag that opens a wallet with a pre-filled transaction.

Generate a QRCheck wallet support
The ideal flow (what we want)
  1. Merchant enters amount
  2. User scans QR or taps NFC
  3. Wallet opens with a pre-filled transaction request
  4. User confirms (authenticated) and sends

This is conceptually similar to mailto: or tel: deep links — and it’s why ERC‑681 is worth reviving.

What works today (most reliably)

The safest cross-wallet baseline is a native transfer with optional value=… (wei) and optional @chainId.

ethereum:0xYourMerchantAddress@1?value=0.01e18

中文：面对面支付建议优先用「原生币转账」做 MVP（最少 ABI 风险、最多钱包能跑通）。

What breaks (and why)

ERC‑20 transfers and general contract calls are where adoption fragments. A link like:

ethereum:0xToken/transfer?address=0xRecipient&uint256=1e6

…requires the wallet to safely construct calldata and present a clear signing UI. Without a standard ABI discovery mechanism, wallets often avoid this to reduce blind-signing risk.

Practical consequence: even if the URI scheme launches the wallet, advanced parameters may be ignored or misinterpreted. That’s why the adoption matrix matters.

NFC: why it’s underused (but powerful)

An NFC tag can store a URI in an NDEF record. In theory, encoding an ethereum:… URI enables “tap-to-open wallet”.

In practice, the UX depends on OS behavior + which wallets register URL handlers, and many wallets don’t advertise NFC-first payment flows yet.

If you’re building POS/NFC flows, focus on:

  • Native transfers first (broad compatibility)
  • Explicit chainId handling
  • Clear signing UX and anti-phishing protections
  • Fallback paths (e.g., WalletConnect) for complex actions