← Back to the library
Web3Applied · 9 min

A Web3 payment feels like developer tooling

“Users must understand networks, gas, token allowances, hashes, and finality before making an ordinary payment.”

ERROR CODES YOU MAY SEE

A code is a clue. Use its meaning and surrounding evidence to narrow the cause.

CALL_EXCEPTIONethers v6 · library

Execution reverted during a contract call, gas estimation, or transaction processing.

Inspect the action, revert data, and receipt when available. A failed simulation does not mean a transaction was submitted or mined.

Official reference for CALL_EXCEPTION (opens in new tab)Code definition reviewed

THE PRINCIPLE

Abstract mechanics, not consequences. Users need amount, recipient, progress, receipt, recovery, and support identity.

FIRST MOVES

  1. Use embedded wallets or passkeys and secure recovery instead of seed-phrase-first onboarding.
  2. Sponsor or quote fees clearly; validate network and asset before authorization.
  3. Track a backend payment attempt independently from the device and transaction hash.
  4. Reconcile receipts, indexers, internal ledger entries, and rewards asynchronously.

TOOLS: THEN → NOW

Injected browser walletsEmbedded wallets, passkeys, smart accounts
User-paid gas for every actionPaymasters, relayers, batched calls

PATTERN SNAPSHOT

type PaymentAttempt = {
  id: string;
  idempotencyKey: string;
  status: "created" | "authorizing" | "submitted" |
    "confirming" | "settled" | "failed" | "unknown";
  transactionHash?: string;
};

CLOSE THE AI. EXPLAIN THIS.

Why should the backend payment ID and blockchain transaction hash be separate identifiers?

Guide reviewed