# ERC-1363: Payable Token

Source: https://www.eipsfordesigners.com/standards/ERC-1363
Agent brief: https://www.eipsfordesigners.com/standards/ERC-1363/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-1363
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Transaction Friction |
| Journey stages | Executing Transactions, Gas & Fees |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-1363 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-1363 |

## UX Impact

Tokens can trigger contract actions on receipt — transfer+action in one transaction instead of approve+transferFrom pattern. Design implications: show single-step payment flows ('Pay 100 USDC' vs 'Approve then Pay'), indicate when tokens support payable callbacks, simplify subscription/purchase UIs. Design decisions: less widely adopted than permit — decide whether to feature-detect and adapt UI, balance simplicity gains against explaining why some tokens have different flows. Directly addresses the Redundant Token Approvals pain point (High severity) — ERC-20's separate approve+call is where most first-time DeFi users abandon. ERC-1363 eliminates that two-step flow at the token standard level.

## Summary

ERC-1363 creates "payable tokens" that trigger automatic callbacks when transferred. Send tokens and the receiving contract automatically executes code - enabling one-step payments where "pay" and "deliver service" happen atomically.

## For Designers

- You can design UI that delivers token transfer automatically triggers service callback.
- You can design UI that delivers transferAndCall sends tokens and triggers action in one transaction.
- You can design UI that delivers receive callback with payment context.

## Applicability

### When to Use

- Your product addresses: payment and service delivery require two steps.
- Your product addresses: approve + transferFrom requires two transactions.
- The flow should deliver: token transfer automatically triggers service callback.
- You are designing a one-click purchase experience with visible states and recovery paths.

### When to Avoid

- Use transferAndCall or approveAndCall for single-tx flow.
- Ensure callbacks always succeed or revert entire transaction.
- Check msg.sender is the token contract in onTransferReceived.
- The flow is a single low-risk transfer where batching adds confusion.

## Problems It Solves

### Payment and service delivery require two steps

Impact: critical

Old way: User sends tokens, then separately triggers service (two transactions)

New way: Token transfer automatically triggers service callback

### Approve + transferFrom requires two transactions

Impact: high

Old way: Approve contract to spend tokens, then call contract to pull tokens

New way: transferAndCall sends tokens and triggers action in one transaction

### Payment contracts need complex state tracking

Impact: high

Old way: Track who approved, pull payments on demand, handle edge cases

New way: Receive callback with payment context, process immediately

### Users can approve but never complete purchase

Impact: medium

Old way: Approval sits unused, confusing for users and contracts

New way: Atomic transfer means payment = action, no orphaned approvals

### Can't include payment context with transfer

Impact: medium

Old way: Transfer tokens, then separately communicate what it's for

New way: Include data parameter with transfer for context

## Anti-Patterns

### Still requiring approve + action for ERC-1363 tokens

Severity: critical

Defeats the purpose, users still need two transactions

Instead: Use transferAndCall or approveAndCall for single-tx flow

### Not handling callback failure gracefully

Severity: critical

Transfer succeeds but callback fails = confusing state

Instead: Ensure callbacks always succeed or revert entire transaction

### Using transferAndCall without validating caller

Severity: critical

Anyone can call your callback with arbitrary data

Instead: Check msg.sender is the token contract in onTransferReceived

### Complex callback logic that might fail

Severity: high

Failed callback means lost funds or stuck state

Instead: Keep callbacks simple, validate inputs, handle edge cases

### Not explaining the one-click benefit

Severity: medium

Users don't know they're getting better UX

Instead: Show "✓ No approval needed" or "One transaction"

### Not showing what callback will do

Severity: medium

Users don't understand what happens after transfer

Instead: Explain "Pay and receive [item]" or "Pay and activate [service]"

## UI Components

### PayableTokenButton

Single-click payment button using transferAndCall
States: ready, confirming, processing, success, error
Props: amount, token, recipient, callData, onSuccess

### AtomicPurchaseCard

Product card with one-click purchase
States: available, purchasing, owned, sold-out
Props: item, price, tokenSymbol, onPurchase

### TransferWithDataForm

Form for transfers with attached data
States: editing, reviewing, sending, complete
Props: recipient, amount, dataFields[], onSubmit

### CallbackStatusIndicator

Shows if transfer callback succeeded
States: pending, callback-executing, success, callback-failed
Props: transferHash, callbackResult, error

### InstantActivationBadge

Indicates feature uses instant activation
States: default, highlighted
Props: featureName, tooltip

## On Monad

### Callback Execution

Ethereum: Callback in same tx means all-or-nothing, which can timeout

Monad: Fast execution means callbacks complete quickly

Design implication: More complex callbacks are viable on Monad

### Gas for Callbacks

Ethereum: Complex callbacks can hit gas limits

Monad: Higher throughput means less concern about callback gas

Design implication: Can do more in onTransferReceived callback

### Confirmation Speed

Ethereum: Pay-and-activate feels slow (12+ second blocks)

Monad: Sub-second finality makes instant activation feel truly instant

Design implication: Emphasize "instant" activation in UI copy

### Reserve Balance

Ethereum: Can spend entire balance on transfer

Monad: 10 MON reserve for async execution safety; guaranteed balance floor for callbacks

Design implication: Show "spendable" balance when using payable tokens

## Key Takeaways

- ERC-1363 = pay and execute in one transaction
- Use for purchases, subscriptions, access control
- Show users the one-click benefit ("No approval needed")
- Validate token caller in callbacks for security
- Keep callbacks simple to prevent failed transactions

## UX Patterns

### One-Click Purchase

Buy item with single token transfer

User flow:

- User views item for sale
- Clicks "Buy Now"
- Wallet prompts to send 500 GAME
- User confirms
- Token transferred AND item received in one tx
- Success: item appears in inventory

Mockup registry key: `concept/bundled-defi` (React UI on the live standard page).

### Subscription Activation

Pay subscription and activate in one step

User flow:

- User selects subscription tier
- Clicks "Pay & Activate"
- Token transfer includes subscription data
- Contract receives tokens + callback
- Subscription activated immediately
- User gains premium access instantly

Mockup registry key: `concept/tx-status` (React UI on the live standard page).

### Crowdfund Contribution

Contribute to crowdfund with automatic reward tracking

User flow:

- User enters contribution amount
- UI shows reward tier earned
- User clicks Contribute
- Tokens transferred with backer data
- Contract mints backer NFT in callback
- User receives NFT + contribution recorded

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

### Token-Gated Access

Pay entry fee and gain access atomically

User flow:

- User views community details
- Clicks "Pay & Get Access"
- Token transfer includes user address
- Contract receives payment
- Callback whitelists user address
- User has immediate access

Mockup registry key: `concept/bundled-defi` (React UI on the live standard page).

## Technical Notes

ERC-1363 extends ERC-20 with transferAndCall, transferFromAndCall, approveAndCall. Receivers implement IERC1363Receiver with onTransferReceived(operator, from, value, data). Spenders implement IERC1363Spender with onApprovalReceived(owner, value, data). Must return magic bytes4 to confirm callback handled successfully.