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.
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.
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 :
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.
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.
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.
Oh nice, that wasn’t there when I last looked, will poke it a bit at the weekend.
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 :Any suggestions? Is the API documented somewhere in detail (OpenAPI or similar)?
Ah, the json.dumps is unnecessary & trips your limit protection - nice :)
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.