Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return amount spent on the outgoing payment grant during outgoing payment creation #2678

Open
2 tasks
mkurapov opened this issue Apr 25, 2024 · 1 comment
Open
2 tasks
Assignees

Comments

@mkurapov
Copy link
Contributor

mkurapov commented Apr 25, 2024

Context

For the web monetization extension (and very likely other use cases), we should know how much has already been spent on the outgoing payment grant.

Whenever we create an outgoing payment, we determine whether the amount for the payment fits within the limits of the issued outgoing payment grant (by summing up all of the other payment that have been created under that said grant). If not, we reject the payment, otherwise, we create it. This accounting is done in the Open Payment resource server (the backend package), because that is where all of the outgoing payments are stored. In the auth server, we only know what the limit for the grant is, but not how much has been spent on it already.

This concerns the Open Payments outgoing payment, meaning there will be no changes in the Admin GraphQL API.

Todos

@mkurapov mkurapov changed the title Return the remaining balance on the outgoing payment grant Return amount spent on the outgoing payment grant during outgoing payment creation May 8, 2024
@BlairCurrey
Copy link
Contributor

BlairCurrey commented May 21, 2024

We talked about the reason for only returning on outgoing payment create, and that is because that is where the accounting is happening. We don't want to repeat that logic in a GET (especially for an entire page). We also concluded that returning in the create is sufficient for the webmon use-case.

Out of scope for this task but I wonder if there would ever be a use case for looking it up later. In that case I guess we could store it in the db on create. Although I imagine that could be stale by the time it's looked up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

2 participants