Summary
This ERC proposes a standard interface for Buy Now Pay Later (BNPL) installment orders on EVM-compatible blockchains. It defines a state machine for installment commerce, cryptographic customer consent via EIP-712, pluggable authorization strategies for token movement, and operator-managed collection, ERC dependencies on ERC-20, ERC-165, EIP-712, and EIP-1271.
The Problem
E-commerce BNPL is a mainstream consumer payment method. Globally, hundreds of billions of dollars flow annually through centralized providers e.g., Klarna, Afterpay, Affirm, that are opaque, jurisdiction-specific, and require merchants to integrate with proprietary APIs.
To our knowledge, no existing ERC addresses the specific requirements of on-chain merchant-financed installment commerce:
Atomic down payment with cryptographic consent. At checkout, the customer must simultaneously authorize the order terms and transfer the down payment. Existing token approval standards (ERC-20 approve, ERC-2612 permit, Permit2) handle the payment but carry no order-specific consent. A customer could consent to terms the merchant later substitutes, or a merchant could create an order without genuine customer consent.
Split authorization for down payment vs. installments. The optimal UX requires two different authorization models in the same order. At checkout, signature-based authorization is preferred — the customer signs once, no prior approval transaction required. For subsequent installments, automatic collection is preferred — the customer should not interact with the contract again after checkout. No existing standard models this two-phase split within a single order.
Defined state machine with off-chain recovery. The order lifecycle must be precisely specified so that off-chain backoffice systems can reliably act on state transitions. Default recovery — debt collection, service termination — is platform-specific and are not part of the standard.
Design at glance
Authorization abstraction (IPaymentAuth)
A core part of the standard is separating payment scheduling from token authorization. A pluggable IPaymentAuth interface handles all token movement, keeping the order state machine stable regardless of how tokens are authorized. Five normative reference implementations are considered:
| Strategy | Token compatibility | Use case |
|---|---|---|
AllowanceAuth |
Any ERC-20 | Simplest; standing approval |
Permit2Auth |
Any ERC-20 (via Permit2) | Can be the recommended option |
PermitAuth |
ERC-2612 tokens only | No Permit2 dependency |
EIP3009Auth |
USDC/EURC (EIP-3009) | Suited for USDC; atomic transfer, no allowance, front-run resistant via receiveWithAuthorization |
MerkleScheduleAuth |
Any ERC-20 | Variable-amount installment schedules committed via merkle root |
The recommended combination for e-commerce BNPL is Permit2Auth (down payment) + AllowanceAuth (installments) — a gasless signature-based checkout with fully automatic subsequent collection. For USDC specifically, EIP3009Auth + AllowanceAuth provides stronger security: no allowance at any stage and front-running protection.
Customer consent (OrderAuthorization)
The merchant calls createOrder at checkout. The customer signs an EIP-712 OrderAuthorization struct off-chain — a typed, human-readable message covering all order terms including both auth strategy addresses. The contract verifies the signature and collects the down payment atomically in the same transaction. EIP-1271 support makes this compatible with smart contract wallets (Coinbase Smart Wallet, Safe, etc.).
The OrderAuthorization type string:
OrderAuthorization(address merchant, address token, uint256 totalAmount,
uint8 installments, uint256 downPaymentBps, uint256 installmentPeriod,
uint256 gracePeriod, uint256 lateFeeBps, address downPaymentAuthStrategy,
address installmentAuthStrategy, uint256 nonce, uint256 deadline)
Order lifecycle
Five terminal states are defined, each with distinct off-chain semantics:
-
Active→Completed: all installments paid -
Active→Defaulted: grace period elapsed without payment (off-chain recovery) -
Active→Cancelled: voluntary termination by merchant or customer -
Active→Refunded: merchant-issued refund terminates the order -
ActivestaysActiveon partial refund:processRefundreducestotalAmountand recalculates remaining installments without terminating the order
Operator management
Merchants can authorize operators (automated keepers, backend infrastructure) to trigger installment collection. Operators call collectInstallment but never receive funds — all tokens flow directly from customer to merchant.
Use Cases
The standard is designed primarily for e-commerce BNPL but the IPaymentAuth abstraction makes it applicable to a broader range of installment payment scenarios:
-
E-commerce BNPL: down payment at checkout, installments auto-collected over weeks/months
-
NFT installment purchases: high-value NFT acquired with trailing installments; marketplace holds NFT in escrow until
OrderCompleted -
DeFi loan repayment: borrower is
customer, lending protocol ismerchant;MerkleScheduleAuthhandles amortizing schedules with variable amounts -
DAO contributor payments: DAO treasury as
customer, contributor asmerchant; milestone gating enforced off-chain -
Token vesting tranches: project treasury as
customer, recipient asmerchant;MerkleScheduleAuthhandles non-uniform cliff+linear schedules -
Protocol fee payment plans: enterprise clients paying access or listing fees in installments
What Is Deliberately Out of Scope
-
Default recovery mechanisms (debt collection, credit reporting, collateral liquidation)
-
Consumer credit compliance (APR disclosure, cooling-off periods) — implementing platforms bear this responsibility
-
Recurring and subscription payments
Reference Implementation
A reference implementation is available at GitHub - asghaier76/BNPL: BNPL ERC Reference Implementation · GitHub
Looking forward to the community’s feedback, particularly on the design decisions listed above. I’ll be monitoring this thread and updating the draft based on the community input.