ahopebailie

I have always been a fan of how Tigerbeetle abstracts away time so you can simulate ticks for testing purposes. Not applicable to all systems but really powerful for their use case.

On the contrary I think both products are excellent.

The issue I have is that we've taken 20 years to find a better alternative than raw card data in Web forms and as a result we're gonna be stuck with a choice of only those 2 wallets when we could have a had wallets as diverse as websites if we'd been able to work together on a solution that was appropriate to the Web platform.

I think you miss the point that card payments should never have evolved to still require us to type sensitive data into a web form at all.

Also, don't forget that 2FA etc are not ubiquitous, especially not in the US.

As I implied, PCI DSS is lipstick on a pig. We could have done much better in the last 20 years. Now Apple and Google are doing it for us and we won't have any choice but to get further locked into their walled gardens.

It's actually about what is supported natively in Web browsers and what the vendors of those browsers have done to make it better.

Sadly you are correct that the mentality of the browser vendors is VERY card (and US) centric so accommodations for other payment methods get very little attention.

This is not a fault of the working group participants who have tried to push for everything from iDEAL to crypto but in the end it's pretty clear we're heading for a wallet-dominated world and we all know who those wallets will come from unless we push back.

This is pretty much the exact distinction between the US attitude to cards and the rest of the world. In the US, the ability to dispute a card tx is just part of life.

Everywhere else the banks have forced poor UX onto merchants in the name of shifting liability and improved security.

This is why the US rolled out chip cards with a signature while everyone else has been using chip and PIN for years.

We're working to make the Web Monetization API a standard that browsers can adopt natively: https://webmonetization.org

The extension helps us bootstrap the ecosystem but a native integration is far superior. Check out Puma browser for an example of the integrated experience for mobile.

This was a straight donation. A thriving Web ecosystem of independent developers and creators building and hosting their own content is what gets us out of bed in the morning.

Credit to Ali Spivak who kicked this all off and helped us realise what a crucial role good platform documentation plays and how important it is to fund good knowledgeable writers.

That's where the idea started but that means the user has to be able to send Bitcoin. The purpose of Interledger is to abstract away that issue which is why Web Monetization is built on Interledger.

You don't have to sign up with Coil to earn. There are other wallets that are on the Interledger network such as Uphold and Gatehub that can give you a payment pointer to put into your site's HTML. If you want your earnings to be converted to BTC that's possible I think.

No. Although it would be great if they did.

This is a pretty good summary.

Interledger (interledger.org) is a protocol stack and a network. The network consists of a number of companies that have setup arrangements to settle payments between them via different payment rails and implemented the Interledger protocol to make those payments.

The Interledger network is used to send payments between these companies consisting of millions of tiny packets (each worth nano-cents) allowing for very small amounts to be sent at close to zero cost.

Coil is one of the companies using the Interledger network as it is perfect for our use case of Web Monetization (which is only viable on a payment network that allows very small payments without a fixed fee).

We originally developed the Interledger protocol at Ripple and there are still folks at Ripple that participate in the community. I think Ripple's incentive for seeing Interledger succeed are well described above.

Those two efforts address different use cases.

Web Monetization is an API for websites that wish to accept a stream of small micropayments as long as the user is on the site. This suits pay-as-you-use content and service models and is a good substitute for advertising revenue as it's passive (no user interaction required).

Web Payments (there are two APIs: https://www.w3.org/TR/payment-request/ and https://www.w3.org/TR/payment-handler/) are discreet payments requested by the website and explicitly authorised by the user. These are best suited to use cases like ecommerce, donations etc.

Google have some great ones which are applicable across the board (it's a standard!), but they are busy being updated: https://developers.google.com/web/ilt/pwa/introduction-to-th...

also: https://developers.google.com/web/fundamentals/payments

There is also some good content on MDN: https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...

The APIs aren't really designed to solve for this.

If the site knows you and has payment credentials stored they won't need to use Payment Request API (although they still can).

Storing payment credentials differs by payment method. If you're talking about card payments then you have to deal with things like PCI-DSS and/or tokenization but there are other ways to pay which may support this use case more explicitly, for example by capturing explicit permission from the user to allow the merchant to make future purchases seamlessly.

This is something we're trying to find a standard protocol for with https://openpayments.dev so that the ecosystem is less fragmented. But, this is not linked to the W3C work explicitly

My expectation is that the PSPs will help to hide the complexity from merchants that don't have the resources to use the (admittedly complex) API directly.

e.g. Stripe already have support for PR API in their SDK

Not true at all.

The ISO20022 RA (Swift) has been involved since the beginning as have numerous banks from Europe and LOTS of non-card payment methods are represented through their associations or scheme participants.

Part of the challenge is that the standard needs implementors to participate and contribute use cases and designs and users and merchants that use these systems to implement and test them.

The PSD2 ecosystem is also still quite nascent so even though we've had Open Banking UK, STET, Berlin group etc engaged they are still figuring out how their systems will work. These APIs are simply a channel by which their systems will ultimately be used.

I've seen some very good Open Banking demos using the PR API and PH API but they aren't in the market yet.

I'll also confess it is a bit of a chicken and egg situation. They won't prioritize support for these APIs until they see adoption by browsers and up to now Edge and Firefox have been slow to adopt. Edge is now Chromium based and has inherited all of the work already done to implement so that has changed overnight and I believe Firefox are keen to progress but just need to get this work on into their pipeline.

Not explicitly but it does come up regularly. The challenge with standards is that they are very slow to solidify so we have to keep ensuring we are tackling a manageable (small) scope.

In my personal opinion recurring payments are quite specific to the payment method. For example, how would one do a recurring Bitcoin payment?

At Coil we are trying to come up with some open standards to address this problem space that we hope will complement the W3C browser APIs. We base our standard around the concept of a "mandate" which the user authorizes a payee to create in against their account and which allows that payee to "push" funds from the account to themselves at specific intervals and for predefined amounts. We prefer mandates to the card-based model because the user is in control and can cancel the mandate at any time.

You can read a bit more about that work here: https://openpayments.dev

Excuse the state of the website it's under a small redesign but the content is mostly there, albeit a little rough right now.

I was originally a member of the web payments community group which existed before payments was on any standards track at W3C.

The high level of interest and activity in the community led W3C to form an interest group to explore if payments was a WG-worthy topic and I also participated in that.

When we finally chartered the WG I was approached to chair and agreed. We've re-chartered twice since and I continue to chair.

The job is made a lot easier by the fact that we have a great W3C staff contact who does all the heavy lifting.

Sorry, link: https://www.theverge.com/2020/1/14/21064698/google-third-par...

Here's a decent write up.

In short, 3rd-party cookies and storage are being blocked (or phased out). This means you can insert an iframe into a page but the cookies/storage it has access to will be partitioned based on the origin of the top-level context.

E.g. If PayPal embeds an iframe in walmart.com's site and the user logs in to PayPal to pay then goes to target.com's site where there is also an iframe embedded the user will have no active session and will need to login again.

I co-chair the working group doing this work. Happy to answer (almost) any questions?

PR API is part of a set of specifications designed to improve payments on the Web. Most importantly, it is the invocation side of a cross-origin payment service ecosystem we're trying to seed.

The other half is Payment Handler API which is less mature but has been rolled out in Chrome and Edge: https://www.w3.org/TR/payment-handler/

Think of PR API as the payment service discovery/invocation side and PH API as the service provider side with the possibility of the service provider being a native app if the platforms supports it (e.g. Android lets apps register as payment apps and Safari + ApplePay works like this already).

The website invokes the PR API (I want to get paid and these are the payment methods I support) and the browser matches the supported methods the website supports to payment apps the user has installed that support the same methods then prompts the user to pick the app they want to use. (Payment apps register/install themselves via the PH API)

If you invoke Google Pay on Chrome today both of these APIs are already in use. Google Pay is deployed as a fully web-based Payment Handler with no special privileges in Chrome.

It's important to note that many of the tricks (like hidden iframes from PSPs) that are used to make payments frictionless today are going to become useless as browsers roll out more changes to protect user's privacy (e.g. killing 3rd party cookies and storage). The privacy improvements are good but they have significant side-effects on UX.

PR API and PH API offer a way for websites to invoke a payment app from another origin (eg. shop.com invokes paypal.com) without losing context (the payment app is rendered in a modal window not via a redirect) and without needing to know up front what payment methods the user supports (good for privacy).

I agree with @mixedbit that there is a risk this doesn't gain sufficient adoption to stick around but I believe the combination of a decreasing number of alternatives and increasing support and interest from browsers suggest it has a very good chance.

We are also working closely with the card networks to support Secure Remote Commerce (SRC) via these APIs providing a significantly better card payments experience than most websites offer today.

Finally, the movement toward payer-initated payment methods whereby the payer or a third-party payment initiation service (think PISPs under PSD2) is handling the payment (as opposed to a PSP on behalf of the merchant capturing the user's card details) suggests the API will gain traction if we can get the design right to support these new payment methods (e.g. SEPA instant credit etc).

If you have strong opinions about factors that will contribute to the success of the API (especially wrt adoption) please provide your feedback on our Github repo linked from the spec.

There is a lot in the wikis that covers our current thinking, the whole process is done in the open.