Simon Metson

Posted on Dec 15, 2020

Payment verification

#vanilla #webmonetization #programming

I wondered if folk had done any thinking about payment verification. I've stumbled across Vanilla, which seems great, and have built it into our application (written up in on our blog), and thought it would be good to compare notes...

Top comments (17)

Brandon Wilson • Dec 15 '20

You can check out this doc on using receipts to verify web monetization payments:
webmonetization.org/docs/receipt-v...

I'd recommend using the public verifier service described there.

Benedict Lau • Dec 15 '20

This one should solve all the exclusive content use cases. Do you know of a way to fetch not only the payment from the single user agent, but the aggregate amount of everyone sharing that payment pointer as either an absolute balance or "last 24 hours"? In theory the service with the receipts should have the data to compile these numbers, but not sure if that's a feature. Use case for this is crowdfunding.

Brandon Wilson • Dec 15 '20

The receipt verifier implementation doesn't currently support that type of balance tracking. By default, it discards all records of a session's payment stream after 5 minutes.
A previous iteration did have some additional balance tracking functionality.

You could have the backend that's submitting receipts to the verifier service use the response of the /verify request to update a dedicated balance store.

Simon Metson • Dec 15 '20

Oh nice, that wasn’t there when I last looked, will poke it a bit at the weekend.

Simon Metson • Jan 31 '21 • Edited

Hey Brandon, finally got a chance to try this & getting a 413 Client Error: Request Entity Too Large for url: https://webmonetization.org/api/receipts/verify error when sending a receipt :

response = requests.post(
            CONFIG.get('wm_org', 'API_URL', fallback='https://webmonetization.org/api/receipts/verify'),
            data=json.dumps(request['receipt']),
            headers= {
                'Content-Type': 'application/json',
            }
        )

Any suggestions? Is the API documented somewhere in detail (OpenAPI or similar)?

Simon Metson • Jan 31 '21

Ah, the json.dumps is unnecessary & trips your limit protection - nice :)

Simon Metson • Jan 31 '21

I notice that Puma seems to have a problem processing ILP's like this & the ones Vanilla makes, which is a bit of an issue in the mobile world.

Benedict Lau • Dec 15 '20 • Edited

proxy payment pointer

Brilliant. While we don't care to verify payments to unlock content, we ran into a related problem because we want to know (real-time-ish) how much money we received via Web Monetization across all readers, and I didn't want to hard-code into Uphold private APIs to query this info. This is a viable path for us :)

I linked to our relevant issue here, but we have some decentralization requirement that this method may not work. My original thought was to query some publicly available information from the transaction, but it seems this is behind Uphold's API and I don't want to tightly couple. I emailed Uphold to see if they have a suggestion but haven't heard back.

Simon Metson • Dec 20 '20

What about doing this the other way round? You know in the front end code when a payment has been made, and what that was paid (e.g. webmonetization.org/docs/counter), why not send that on into a tidbit like Prometheus or similar to render?

Simon Metson • Dec 20 '20

Or send something to an analytics tool. I’ve been using Fathom, and setting goals to record whether a visitor has coil enabled etc.

Benedict Lau • Dec 20 '20

Because the client is not trusted, anyone can report any number via an unprotected call. This is why we have to read off some verified place such as aggregating receipts.

Simon Metson • Dec 21 '20

Ah right. I think taking this into your own hands wouldn’t be horrendous (famous last words), if you can’t find a place that will give you the dashboard you need.

Benedict Lau • Dec 19 '20

Got some answers from Uphold side about a verification path from the reserve chain endpoints. Our project won't pursue this path, but leaving response here in case anyone is wondering.

Q: Is there a way to read this information outside of the Uphold authentication? For example, directly on the Reserve Chain using some associated public key (without Uphold login)?

A: No, you can only access the reserve chain endpoints (uphold.com/en/developer/api/docume...) with authentication.

Q: If I need to use Uphold’s API, as I need to read account information on behalf of other Uphold account holders, do I need to register a Business Account and set up each account with the Client Credentials Flow? Under this auth flow, are we expected to read only the account that belongs to us, or can request for other account’s read-only tokens and read data on their behalf? uphold.com/en/developer/api/docume...

A: If you need to read account information on behalf of other uphold account holders you need to have a business account.

Simon Metson • Dec 15 '20

Great :) I think the vanilla folk have some plans for that sort of thing, and they’ve been very helpful when I’ve mailed them.

Benedict Lau • Dec 15 '20

Great. If there is broader scope conversation over email with them that you feel helpful to pull me in, feel free to cc. me benedict [at] compost.digital.

Simon Metson • Dec 27 '20

Sample code on github.com/audiotarky/wm-flask - will tweak some more over the coming week.

Simon Metson • Jan 1 '21

Started a separate thread for this community.interledger.org/drsm79/p...

View full discussion (17 comments)