coinbase
[SPECS] Payment payload can't be linked to a specific payment requirements
Hi everyone and thanks for your work!
The specifications defines that you can have several payment requirements for an URL:
// List of payment requirements that the resource server accepts. A resource server may accept on multiple chains, or in multiple currencies. accepts: [paymentRequirements]
But the specifications indicates that, when you send a payment, you don't say which requirement you want to fulfill, you just send a payment payload indicating which scheme.
Client selects one of the paymentRequirements returned by the server response and creates a Payment Payload based on the scheme of the paymentRequirements they have selected.
Now, on the server, if I have set two paymentRequirements with the same scheme for a specific URL, I will receive only one payment payload. How can I know which one the user wants to fulfill ?
Am I right ? or does it means that you can only have one payment requirements per scheme ? which would be a bit strange...
+1 to that. If we are to support multiple tokens per (network, scheme) pair at some point, the current matching does not make sense. Maybe have that matching as part of v2 spec?
UPD: If we add a new asset field to specify token contract address, that could be something like v1.1 spec, backwards compatible to the current spec.
+1 to that. A more robust approach would be to associate an ID with a PaymentRequirement and have the PaymentPayload identify which requirement it fulfills.
Thanks to @miljantekic this is back on our radar.
We will add this shortly, likely via their #322 PR. We're just taking some time to consider how we want to do it to ensure the interface is solid.
We will be sure to have it formally included for the v2 spec. For now, it being optional and backwards compatible will suffice
Stay tuned
Hey @CarsonRoscoe just to bump this issue. We ran into a similar problem in Faremeter as part of supporting many tokens on Solana, and addressed the short term pain with what @ukstv was suggesting:
https://github.com/faremeter/faremeter/commit/0d3e5db170a458b9e1c16b63191b557006f07529 https://github.com/faremeter/faremeter/commit/67e74fc8b6b365af211068005e937107ff44bd6b https://github.com/faremeter/faremeter/commit/f445583f7871623bc96f4fd32a0594f8f45f56b2
It's backwards compatible, and doesn't preclude moving to some explicit ID in future.
My take-away from this thread may have been misguided. I interpreted this from the server-side needing to link PaymentPayloads' with PaymentRequirements', but I missed the inquiry into client side selection.
Our client libraries, such as x402-axios, offer a paymentRequirementSelector param to solve this client-side. For those who simply want to implement their own prioritization logic for selecting a PaymentRequirements from the accepts array of the Payment Required response, this selector should be sufficient.
For those looking for a server-side solution, where during processing you want deeper control into linking back the PaymentPayload with the PaymentRequirements, I am attempting to solve this in the v2 spec upgrade, and encourage you to add your thoughts
Yah, this issue is specifically about the latter problem.
For those looking for a server-side solution, where during processing you want deeper control into linking back the PaymentPayload with the PaymentRequirements, I am attempting to solve this in the v2 spec upgrade, and encourage you to add your thoughts
The payment requirement selector can't help the situation with multiple assets on one network/scheme, because the middleware doesn't have enough information to pass the correct requirements to the facilitator.
Understood, so it really boils down to this code being unable to match on asset or other PaymentRequirements' fields.
Will make sure this is addressed in v2. There is a gap here for sure