Discuss adding support for rejecting/completing an incoming payment to the Admin API

[AlexLakatos]

[wilsonianb]

Completing an incoming payment is currently possible via Open Payments:
https://docs.openpayments.guide/reference/complete-incoming-payment

Rejecting an incoming payment is indirectly possible when incoming payment grant authorization requires RO authorization:

• feat(auth): allow non-interactive grants for incoming payments #588

[AlexLakatos]

This issue is for the Admin API, so that the Incoming rafiki instance can early complete/reject a payment that was created by a 3rd party.

[mkurapov]

This issue is for the Admin API, so that the Incoming rafiki instance can early complete/reject a payment that was created by a 3rd party.

This should not be limited to the incoming rafiki instance. Similar to the createReceiver mutation, we should be able to complete a incoming payment at a remote rafiki instance. Use case: whenever we are creating a fixed-send P2P payment, the incoming payment actually does not have an incoming amount, meaning, there isn't an easy way to trigger a completion of an incoming payment over the Admin API, and we have to rely on the Open Payments client or wait for the payment to expire. Instead, we should just have an API call happening in the outgoing-payment.completed webhook to complete the incoming payment.

[mkurapov]

Alternatively we could add a PATCH for the incoming payment to set an incoming amount after quote/outgoing payment creation or something. That way the sender can be explicit about whether they want to payment to finish exactly or not.

We don't like this PATCH

[sabineschaller]

For completing:
What if we had an Admin API endpoint that used Open Payments under the hood to complete incoming payments. Only clients that created an incoming payment can complete it via Open Payments. Hence, only incoming payments created by Rafiki itself can be completed by it, allowing for fast completion in the peer-to-peer use case. In contrast, we wouldn't accidentally complete incoming payments that may still be receiving in the future, like in the web monetization use case, because the extension (=client) created the incoming payment and Rafiki cannot complete it via OP.
ASEs would use this admin API endpoint when they receive the outgoing payment completed webhook.