Web Monetization for the Streaming Dev (2 Part Series)
WM is not for traditional e-commerce checkout methods. For shopping carts there is a completely different spec called Payment Request/Payment Handler.
The Web Monetization spec seems very preliminary, like a early work in progress. Yet I am grateful to get such an early look at what it might become. It holds a vast amount of promise. There are many, many open questions that I will get to as I learn more. I have to take it as it is. Final analysis will come later.
The current design of Web Monetization is easy to implement. However, as currently implemented, it seems to lack the ability to control what is happening in the back ground. The monetization experience is almost invisible. Probably a primary design goal. Laudable. But also frustrating for control freaks not to see and control the payment stream. For example, there doesn't seem to be a way to specify an amount to send to a web site. I suspect there are a bunch of things going on under the covers and I just don't see them yet. Coil (my monetization provider) seems to be controlling what the web site gets from me and at what rate.
Anyway, I see two primary use cases for Web Monetization, as proposed.
1) Adjust user experience according to the user's desire and ability to pay.
As a web site owner, you will want to detect and respond to the user's payment stream. If user is streaming payments to you then you better do something, otherwise why would they pay you? Shut down ads for paying customers. Provide paywalls for premium content. This is all basic user interface design in the monetization world. All web site owners will need to make basic considerations for monetized users.
2) Charge for Streaming content.
Streaming content is where this Web Monetization spec holds the most interest for me. Streaming videos, movies, group chats. The frustrating part of this is that I don't see how to control all the details yet.
Also, I should break it down this way.
A) If you have your own web site then you have control over the monetization policies. You have the
monetizationprogress event as a place to enforce your policies. That's good. But if your policies get complex then there will be a lot of code to write.
B) If you are a content creator and you can't afford your own web site and custom programming to set up your own monetization policies then you are going to be stuck with whatever your platform provider policies are.
It is all about policies and control. Basically, for the consumer, its my wallet, my money. I want control over my wallet.
For content creators, they want control over their content and to set those policies for content delivery.
In other words, Web Monetization as currently implemented, is not the ideal peer-to-peer electronic cash system.
Its going to get interesting as we work through this. All thoughts and opinions are subject to change.