CAIP-358: Universal Payment Request Method

[lukaisailovic]

Discussion regarding the #358

This CAIP standardizes a wallet_pay JSON-RPC method enabling one-click cryptocurrency payments across wallets and dapps. Allows merchants to specify multiple payment options (cross-chain assets) in a single request, letting wallets automatically select the optimal payment method based on user's available assets. Eliminates the current multi-step payment flow (select token → select chain → generate address → manual transfer) by moving payment choice and execution to the wallet, reducing friction from 4-6 clicks to a single interaction.

[kdenhartog]

So the reason I brought up #358 (comment) was because the current spec doesn't specify how the page should communicate with the wallet via the scripts.

If this is done via window.ethereum.requests() then it ends up not being chain agnostic and would introduce complexity if say for example the site is expecting payment on SOL.

Similarly, if this relies upon CAIP-25 permissions to be made available before accessing the RPC then I think that means we get forced into doing a connection setup before using the RPC which I'd like to avoid since we don't need permissions here I'd think.

That's why I'm thinking we should establish where we want it to be passed and how (albeit this might be needed in a different spec)

[glitch-txs]

Do you mean a sort of EIP-6963 but chain agnostic? Wouldn't be better to split that into a different protocol than having it attached to the payments one? Then we can refer to that protocol from this one.

[glitch-txs]

why don't we just add a chain value inside 6963 info object? then we could just do the request like with any other method? (donno if it's possible but just throwing ideas 😄)

[lukaisailovic]

@kdenhartog Thats intentional.

This method doesn't specifically rely on either CAIP-25 or EIP-6963. Also not sure wdym about permissions in CAIP-25. In any way, I don't want to couple the interface with the delivery method.

@glitch-txs 100% agree

[kdenhartog]

I think what you're saying here makes sense @glitch-txs and following why you went this direction now @lukaisailovic. Ok, I agree this makes sense to separate these two. I don't mind your idea of doing this inside the info object, but I'd venture to guess we'd be better off first seeing what @jordaaash and the Solana folks want to do about this too. If we're going to build a chain agnostic interface, we'll need to reconcile the two current approaches into one (6963 + wallet-standard) and probably have to factor in the likes of Sui/Cardano/etc.

[ukstv]

Folks, just FYI there is some adjacent thing happening right now https://www.x402.org with regards to payment requests. Have no time for a meaningful contribution to the discussion here yet, but it might be cool if this CAIP and x402 paywalls (or even their PaymentRequirements data structure) could be harmonized.

[lukaisailovic]

If there is a compelling use case to harmonize/sync the data structures I'd be up for that, but I don't see it currently tbh

[ukstv]

An obvious use case is the paywall html page like https://www.x402.org/protected - IMO, it might make sense just to pass the x402 PaymentRequirements to the user's wallet instead of converting them.

I am not going to pedal the theme forward though, as I am not certain yet what the leverage could be. So, sorry, yet another distraction. Keep up the great work!

[kdenhartog]

It appears to me like this would sit above this RPC. Right now, the structure of x402 is to create it's own window object specifically for payments only.

While this RPC is specifically focused on payments, we'll need to decouple this from specific chain provider objects like window.ethereum or window.solana. As @glitch-txs suggested above, we should be defining some separate object (not payment specific) like window.wallet and exposing it separately within there.

Also, do you by chance know why they chose to define a separate x402 object to hange off Window rather than just polyfilling over payments request API?

Probably worth mentioning too, their design doesn't allow for a cross device flow like what's being proposed here. This will make it specifically web focused rather than being able to handle either web payments or in person transactions like what CAIP-358 did.