feat: Web Monetization + Open Payments: Part 2 Payment Sessions #164

sidvishnoi · 2025-10-29T12:16:14Z

PR Checklist

Linked issue added (e.g., Fixes #123)
If blog post was added:
- Ensure images have been optimised
- Update dates to reflect the actual publishing date when merged (file names, folder names, and frontmatter)

Summary

Follow up of #163.
Aiming to get it published by Dec 8.

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

src/content/blog/2025-12-03-web-monetization-open-payments-part-1-connecting-wallet.md

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

JoblersTune · 2025-12-08T08:27:23Z

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

+  addedLinkElements.forEach((elem) => {
+    const id = assignId(elem)
+    const walletAddressInfo = await validateAndFetch(elem.href)
+    dispatch('start_monetization', { walletAddressInfo, id })


Again I realise that you're assuming base knowledge of WM but I think clarity just makes reading easier. This can make it seem like monetization is starting all link elements simultaneously rather than setting them up to all be available for receiving. Unless I am behind on changes, my understanding is that each wallet address takes a turn to get paid? It might be nice to clarify that above or below. Like being on a site with 10 wallet addresses costs no extra per second than being on a page with 1.

I replaced the start_monetization with setup_monetization and also added a paragraph about multiple link elements in start. I hope that reduces the confusion.

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

JoblersTune · 2025-12-08T08:45:09Z

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

+
+### Manually finding minimum sendable amount
+
+We use a probing method to find the minimum sendable amount. For example, if we try to send MX$0.01, we receive a "non-positive receive amount" error. We note this error and then attempt MX$0.02, which also fails.


This makes it sound like you are trying to make payments with no upper boundary, like we try to send this and it doesn't work so we try sending more. What you're actually doing is checking the quotes. I think in terms of building confidence in new standards it helps to talk in ways that don't make people anxious before they understand the full context. So you could phrase this around quotes, or non fulfill-able payment requests or something rather.

Addressed in da945bb.

JoblersTune · 2025-12-08T08:47:30Z

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

+We observed that MX$0.16 was not sendable, while MX$0.32 was sendable. Therefore, the minimum sendable amount lies somewhere in between. This is a textbook use-case of the binary search algorithm!
+The midpoint between the two amounts is MX$0.24, which is sendable, but it is still above the minimum sendable amount. When we find the midpoint of MX$0.16 and MX$0.24, we get MX$0.20, which is also not the minimum sendable. After some back and forth, we determine that MX$0.17 isn’t sendable, but MX$0.18 is, concluding that MX$0.18 must be the minimum sendable amount.
+
+Each test to determine whether an amount is sendable or not costs us one create quote request, which can add up significantly and delay the time it takes to send money to the recipient. To optimize this process, we can utilize currency exchange rates. Instead of starting our tests from MX$0.01, MX$0.02, MX$0.04, and so on up to MX$0.32, we can begin at MX$0.18. This way, we’ve trimmed our search space by a considerable margin. We still need to confirm whether the amount is sendable, as there may be associated fees, and to verify if it is indeed the minimum sendable amount. However, we have minimized the number of unnecessary requests.


You have now increased the amount sent, it would be nice to add an explanation of increasing the time period too, to keep average payments / second at a relatively constant pace. Because, again, this feels like you agree to one thing up front in the extension and now all of these changes are happening outside of your control and readers may want some reassurance that they won't suddenly be sending 18x what they had planned per second.

Addressed in 7f00c56.

JoblersTune · 2025-12-08T08:49:37Z

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md

+
+Before creating the outgoing payment with our previously acquired tokens, the Open Payments API requires us to set up a receiving channel.
+
+The process begins by creating an incoming payment grant on the receiver's wallet. This grant is non-interactive, meaning the user does not need to manually approve each incoming payment, which would be very cumbersome. Once we obtain the permission, we can proceed with creating the actual incoming payment.


I find this confusing on first read. You say you don't need approval but you're waiting for permission. It would help to be clearer about user approval vs authorization servers granting permission.

Addressed in 5b9ed35.

netlify · 2025-12-08T11:10:17Z

✅ Deploy Preview for developers-preview ready!

Name	Link
🔨 Latest commit	`988d0e3`
🔍 Latest deploy log	https://app.netlify.com/projects/developers-preview/deploys/6936b72b65c08d0008624926
😎 Deploy Preview	https://deploy-preview-164--developers-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

DarianM reviewed Dec 1, 2025

View reviewed changes

src/content/blog/2026-12-08-web-monetization-open-payments-part-2-connecting-wallet.md Outdated Show resolved Hide resolved

feat: Web Monetization + Open Payments: Part 2 Payment Sessions

323423d

sidvishnoi force-pushed the sidvishnoi/wm-ext-op-part-2 branch from 13b9580 to 323423d Compare December 4, 2025 13:27

sidvishnoi marked this pull request as ready for review December 4, 2025 13:27

don't use relative links

098567d

sidvishnoi requested review from JoblersTune and melissahenderson December 4, 2025 13:30

fixup links

ceafd1b

melissahenderson reviewed Dec 4, 2025

View reviewed changes

JoblersTune reviewed Dec 8, 2025

View reviewed changes

sidvishnoi added 2 commits December 8, 2025 16:17

address feedback from Melissa

81f6420

address feedback from Sarah

a722dba

sidvishnoi added 6 commits December 8, 2025 16:42

Merge branch 'main' into sidvishnoi/wm-ext-op-part-2

1edfefe

address feedback from Darian; add link to create quote request too

bb0a856

feedback Sarah: make quoting clear - instead of making payments

da945bb

feedback Sarah: add note about rate of pay even with high minSendAmount

7f00c56

feedback Sarah: make incoming payment grant clearer

5b9ed35

fix: use full URLs for cross-linking articles

988d0e3

sidvishnoi requested review from DarianM, JoblersTune and melissahenderson December 8, 2025 11:33


		### Manually finding minimum sendable amount

		We use a probing method to find the minimum sendable amount. For example, if we try to send MX$0.01, we receive a "non-positive receive amount" error. We note this error and then attempt MX$0.02, which also fails.


		Before creating the outgoing payment with our previously acquired tokens, the Open Payments API requires us to set up a receiving channel.

		The process begins by creating an incoming payment grant on the receiver's wallet. This grant is non-interactive, meaning the user does not need to manually approve each incoming payment, which would be very cumbersome. Once we obtain the permission, we can proceed with creating the actual incoming payment.

feat: Web Monetization + Open Payments: Part 2 Payment Sessions #164

Are you sure you want to change the base?

feat: Web Monetization + Open Payments: Part 2 Payment Sessions #164

Uh oh!

Conversation

sidvishnoi commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

Summary

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

JoblersTune Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

sidvishnoi Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

JoblersTune Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

sidvishnoi Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

JoblersTune Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

sidvishnoi Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

JoblersTune Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

sidvishnoi Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

netlify bot commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for developers-preview ready!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

sidvishnoi commented Oct 29, 2025 •

edited

Loading

sidvishnoi Dec 8, 2025 •

edited

Loading

netlify bot commented Dec 8, 2025 •

edited

Loading