---
title: Wallet RPC for Payment Request
description: "A high level RPC so sites can request payments to a wallet"
author: @kdenhartog (Kyle Den Hartog)
discussions-to: <URL>
status: Draft
type: Standards Track
category: Interface
created: 05/14/2025
requires: EIP-1193
---

## Abstract

Today, it’s possible for a DApp to engage a user with a multi-click flow in order to complete an e-commerce purchase. This is done through the usage of various RPC calls made to a wallet using either EIP-1193 or a similar design. However, this approach is very low level and leads to a poor UX. In this EIP, we’ll discuss creating a very specific high level RPC call specifically for the purpose of online checkouts and payment requests. This will allow wallets to facilitate the complexity on behalf of the user such as performing swaps, bridging, and other security checks along the way on behalf of the user to create a more seemless UX for e-commerce use cases.

## Motivation

Currently, if a DApp wishes to complete an online checkout flow using the current RPC’s made broadly available by wallets it must do the following:

1. Request the users wallet address
2. Check the user has the correct assets on the correct chain
3. Submit a sign request for a transaction to have those assets sent

This is in an optimized flow though where the requested asset or token is already on the correct chain and is available for transfer to the recipient. If the assets are not already available, the UX for this leads to a scenario where the user may have to do one of the following:

1. Purchase or transfer assets from a custodial service or on-ramp provider.
2. Bridge the assets to the correct chain
3. Swap currently owned assets for the assets being requested

In this EIP, we’ll put forward a simplified RPC that allows this to all be handled by the wallet via a high level RPC call specifically designed for completing a payment request such as during an e-commerce purchase.

## Specification

### RPC Interface

{
	"amount": "0.01814",
	"asset": "eip155:1:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
	"chain": "0x1",
	"recipient": "0x123abc",
}

### Semantic Definitions of Properties
- Should this use CAIP identifiers instead to be chain agnostic?

amount: This is the amount of the particular asset being requested. It MUST be denominated as a JSON number according to [RFC8259](https://datatracker.ietf.org/doc/html/rfc8259).

asset: This is the specific asset that MUST be sent to the recipient on completion of the transaction.

chain: This is the identifier of the chain assets should be sent to. This should be formatted as an EIP-155 identifier.

recipient: This is the address the recipient expects to receive the assets at upon completion.

### Call Example

const txnHash = await window.ethereum.request({
	method: "wallet_requestPayment",
	parameters: {
		"amount": "0.01814",
		"asset": "eip155:1:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
		"chain": "0x1",
		"recipient": "0x123abc",
	}
});

## Rationale

- Discuss current UX flows that are controlled by the current RPC design
- Mention why this is an important use case relative to e-commerce and web payments
- Talk about intentional high level interface meant to allow wallets to innovate on safety and composability while making the UX remain seemless and not break for DApps

TBD

## Test Cases

<!--
This section is optional for non-Core EIPs.

The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed

TODO: Remove this comment before submitting
-->

## Reference Implementation

<!--
This section is optional.

The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed.

TODO: Remove this comment before submitting
-->

## Security Considerations

- Wallets should be checking the recipient wallet address is well-known and not on a know ban list.
- Wallets should be displaying the eTLD+1 to the user that’s submitted the request.
- This is important so that malicious iframes in Ad’s can’t trick the user into making a payment they shouldn’t
- How do we intend to prevent a malicious extension/XSS attack from changing the recipient wallet address?
- The wallet should automatically reject requests from sites for:
- no secure contexts
- request already declined
- ???
<!--
All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

The current placeholder is acceptable for a draft.

TODO: Remove this comment before submitting
-->

Needs discussion.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).