Hi Marvin On 4/24/26 17:32, Marvin W. via Standards wrote: You're right, and I saw others have raised the same point in the MUC. I've submitted a new revision on Github that removes the registry for payment schemes, systems and proof formats. A payment option is now a payment URI, and the payment system is identified by that URI scheme. The only registry that remains is the invoice-request service-context list (muc-entry, file-upload etc.), which is still XMPP application semantics. I agree on the substance and the new revision is now even more generic because payment systems are purely identified by their URI schemes. I've also generalized the prose in certain areas. I did however keep a small number of illustrative examples. This follows established XSF practice of naming concrete third-party technologies as examples. For example XEP-0266 names specific codecs (Opus, Speex, G.711), without pretending to be exhaustive. Fair. I've removed the "amount" attribute entirely in the latest revision. The amount, currency and beneficiary are now carried inside the payment URI and governed by that scheme's own standard and we define no amount or currency syntax of our own. I've kept "display-amount" to avoid clients having to be able to parse payment URIs, but it's non-authoritative. Yes thank you, the XEP is now updated accordingly. Regards JC > Marvin > > On Fri, 2026-04-24 at 10:26 +0000, Daniel Gultsch wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Payment Required >> Abstract: >> This specification defines an XMPP protocol extension that enables >> services to require payment before granting access to a resource. >> It provides a payment-system neutral invoice format supporting >> multiple concurrent payment options, including bank transfers >> (SEPA, IBAN, UPI) >> and instant-settlement networks (Lightning Network), and integrates >> with the existing CAPTCHA challenge mechanism defined in XEP-0158. >> >> URL:https://xmpp.org/extensions/inbox/payment-required.html >> >> The Council will decide in the next two weeks whether to accept >> this proposal as an official XEP. >> _______________________________________________ >> Standards mailing list --standards(a)xmpp.org >> To unsubscribe send an email tostandards-leave(a)xmpp.org > _______________________________________________ > Standards mailing list --standards(a)xmpp.org > To unsubscribe send an email tostandards-leave(a)xmpp.org

I can see why you want this. But I'm also a bit concerned abmut the security implications of having a possible "$2" label on a $2000 payment.

It's non-authoritative, clients can slap a "cannot verify this value, check the price on the next step" sticker on it as necessary.

the URI scheme won't be able to show the amount to the user, which sucks. If a client can't display the amount because it doesn't understand the scheme, it's better to tell the user that explicitly ("Unknown payment scheme.") rather than some vague warning that the value might not be accurate, while still displaying the amount as if it's correct. And where the client does understand the scheme, that value is redundant and should be ignored by the client anyway. which could lie about the actual payment amount. If we're going to have one potentially misleading value, let's go the whole way and have multiple? No. It's possible the label could mention an amount, but it won't be displayed in the same way as the explicitly unknown transaction amount, and the sender would have to expect the recipient doesn't have support for the scheme, otherwise the mismatch will be clear. _______________________________________________ Standards mailing list --standards(a)xmpp.org To unsubscribe send an email tostandards-leave(a)xmpp.org