Meta-Transaction Payment

Overview

The payment flow begins with a structured payment request containing the merchant, asset, amount, chain, nonce, and expiration. The customer signs the request with the wallet controlling the payment asset or account. A relayer submits the signed authorization to a compatible smart contract.

The contract verifies the signature, checks that the authorization has not been used, and executes the payment. Token approval may be required unless the token supports permit-style signatures or the smart account already has authority.

This design can improve conversion by removing the need to acquire native gas currency. It is especially useful for stablecoin checkout and consumer applications. However, the sponsoring party needs fee budgets, rate limits, and abuse prevention.

Payment status should not become complete merely when the message is signed. The relayed transaction can fail, expire, be censored, or remain unconfirmed. Monitoring must verify the correct contract event, amount, recipient, and finality.

Customer messaging should explain whether the experience is truly sponsored or whether costs are included elsewhere. A gasless interface is a fee-allocation model, not a zero-resource blockchain transaction.

Merchant reconciliation should record the payer’s signed authorization separately from the relayer’s transaction sender. The on-chain sender field may identify the relayer, while the payment contract or event identifies the actual customer account. Systems that inspect only the top-level sender can misattribute the payment. The receipt, signed message, nonce, and invoice reference together provide a more complete audit trail.

Relayer outages should not erase the signed payment intent or create duplicate submissions during retry.