Web Monetization Community

loading...

Payment verification

drsm79 profile image Simon Metson ・1 min read

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...

Discussion (17)

pic
Editor guide
Collapse
wilsonianb profile image
Brandon Wilson

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.

Collapse
benhylau profile image
Benedict Lau

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.

Collapse
wilsonianb profile image
Brandon Wilson

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.

Collapse
drsm79 profile image
Simon Metson Author

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.

Collapse
drsm79 profile image
Simon Metson Author

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

Collapse
drsm79 profile image
Simon Metson Author • 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',
            }
        )
Enter fullscreen mode Exit fullscreen mode

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

Thread Thread
drsm79 profile image
Simon Metson Author

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

Collapse
benhylau profile image
Benedict Lau • 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.

Collapse
drsm79 profile image
Simon Metson Author

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?

Collapse
drsm79 profile image
Simon Metson Author

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

Collapse
benhylau profile image
Benedict Lau

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.

Thread Thread
drsm79 profile image
Simon Metson Author

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.

Collapse
benhylau profile image
Benedict Lau

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.

Collapse
drsm79 profile image
Simon Metson Author

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.

Collapse
benhylau profile image
Benedict Lau

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.

Collapse
drsm79 profile image
Simon Metson Author

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

Collapse
drsm79 profile image