Max Kurapov

Hmm, after taking a quick look I think it’s because in the webhook request handling we use ``` const amt = payment['receivedAmount'] as Amount ... await mockAccounts.credit(acc.id, amt.value, false) ```...

@wilsonianb Thanks for the notes. A few questions (and please correct any of my assumptions): 1. What is the route for the backend account provider? Based on your comment >...

1. Makes sense, that is what I had assumed. Thank you for the clear diagrams! 2. I can see that adding an extra hop could cause an issue where there...

@matdehaast that makes sense to me - thanks to the clarification. I'm imagining some sort of `/incoming-payment` route that on the account provider side just does a simple payment pointer...

What if we did the same flow as outgoing payments, where we publish a webhook on incoming payment creation, and then we have a GraphQL call to rafiki to void...

That makes sense. In that case, it still _feels_ like the sync call to the account provider during incoming payment creation like the straightforward solution: - No need to track...

@adrianhopebailie please correct me if I'm wrong but basically the proposed solution from the chat during the call is a combination of 1) add this synchronous call to the account...

@matdehaast wanted to add more context here. I believe the current mechanism actually lives on the RS, since on an Open Payments requests you can just set `authorization: GNAP dev-access-token`,...

@mankins This is a good approach, I was just clarifying previously that the existing mechanism (with the `dev-access-token`) lives on the resource server side and not originally on the authorization...

Maybe we could also add this flag to `validateHttpSigHeaders`, or directly as one of the first checks in `grantContinueHttpsigMiddleware` ? otherwise we will still need to provide the http header...