On 4/24/26 15:27, techmetx11 via Standards wrote:

Nice XEP. I wonder if Monero could be added to this?

Thanks, and sorry for the delayed response. After the latest revision a payment option is just a payment URI identified by its scheme. So a monero: URI will work with a client (or wallet) that recognizes that scheme. Different payment types have different proofs, so that's an additional nuance to keep in mind. With Monero you can't verify from a public txid (amounts and recipients aren't on-chain) so Monero relies on an out-of-band transaction proof. So concerning the proof-types, the issuing service should declare the proof type as "proof" (and not "txid") on the option and the payer echoes it (together with the proof itself).

Also, another note: If the client sent a payment but the server is waiting for it to confirm properly (and it doesn't really care about the payment proof), How would we signal to the client to wait a certain amount of time before it tries again?

Good catch, this is something I missed. The latest revision adds a payment-pending reason plus a retry-after attribute (seconds), returned with stanza error type of "wait" (per RFC 6120). The payer backs off for the indicated interval and retries the same session without re-paying. JC

On 4/24/26 11:26 AM, 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@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

---

Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Hi Marvin On 4/24/26 17:32, Marvin W. via Standards wrote:

I don't believe the XSF should maintain a registry of payment schemes or systems or specific proof types for payment schemes. This is not our field of expertise and this should be happening elsewhere. I understand with RFC 8905 there is already some standard and a corresponding registry and we could entirely rely on that (or any other open standard with a suitable registry) instead of doing our own. 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 also would want to refrain to include any specific crypto-currency network or technology in a specification document, because else there will be a ton of stuff to specify: The industry site CoinMarketCap lists more than 150 "Layer 1" crypto-currencies and "competition" in the industry is largely about being mentioned in some "official" sounding documents, so soon everyone will want to have a XEP if we open that can of worms.

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.

There's also a very unhelpful part where you say that currency is ISO 4217 or non-ISO code. That makes it effectively "put anything here". The part where the amount field also includes the currency code is also weird to me (usually we would want to use our XML syntax instead of a custom syntax), but that's a minor.

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.

So my suggestion is to mostly piggy-back on top of RFC 8905 (or any other suitable open standard specification) and have lighting or whatever cryptocurrency network you want to support be integrated with those people that actually do know payments much better than the XSF. 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@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org

---

Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org

I've kept "display-amount" to avoid clients having to be able to parse payment URIs, but it's non-authoritative.

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.

On 13/6/26 10:52, JC Brand wrote:

On 6/12/26 18:44, Stephen Paul Weber wrote:

...

...

I've kept "display-amount" to avoid clients having to be able to parse payment URIs, but it's non-authoritative.

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.

Yes, that's the risk, which is why I mention it in the security considerations.

Perhaps we should just remove it, but then clients which don't know the URI scheme won't be able to show the amount to the user, which sucks.

Also, if we removed "display-amount", there's still a "label" field which could lie about the actual payment amount.

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

_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org

Perhaps we should just remove it, but then clients which don't know 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.

Also, if we removed "display-amount", there's still a "label" field 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.