Discussions

Outgoing payments are currently authorized by including `authorized: true` in either a create or update request. The `create` grant action is required to create. Instead of requiring the `update` (and `authorize`) action to authorize via update, what if there was a `POST https://openpayments.guide/alice/outgoing-payments/{id}/authorize` endpoint? Update requests would then be intended for updating the send or receive amount (but additionally support authorizing, just like in create). This saves the server's initial auth check from having to parse the body (checking for `authorized: true`) to determine the relevant grant action. Instead: - create request requires `create` action - update request requires `update` action - authorize request requires `authorize` action The server can later check for `authorized: true` when it is actually creating or updating a payment and check the grant (it is already checking the grant at that point for access limits).

in the POST and GET request responses of incoming and outgoing payments?

What is the grant access action(s) required to update an outgoing payment's `sendAmount` or `receiveAmount` (via `PUT`)?

The current assumption is that when creating an outgoing payment the provider will return immediately with a "201 Created" response. It will then asynchronously: 1. Query/create the receivingPayment at the receiving provider, and then 2. Get rates estimates for the payment based on the payment details (ILP Address and Secret) it has received. As these async processes are completed the outgoing payment object is updated and eventually its state moves to "prepared". If the outgoing payment is created with a receivingAccount (and not a receivingPayment) then the provider will create an incoming payment at the receivingAccount and update the outgoing payment's receivingPayment property to the URL of that incoming payment. There are use cases such as Web Monetization where the client creating the outgoing payment might want to get the URL of the receivingPayment as soon as it has been created and not have to poll the resource. i.e. The first of the two steps above should be executed synchronously. Should it be the default behaviour for a sending provider to synchronously create an incoming payment at the receiving provider or should we provide a flag for the client to request this behaviour?

for listing incoming and outgoing payments

to allow for the web monetization use case.

Do we allow for the creation of incoming payments with an incomingAmount assetCode and assetScale different from the underlying account's assetCode and assetScale?

To make the perspective from the sender.

https://docs.openpayments.guide/reference/create-outgoing-payment#amounts fixed-send-amount payment: >When the sending account provider has finished preparing the payment it will set the value of the `receiveAmount` fixed-receive-amount payment: >When the sending account provider has finished preparing the payment it will set the value of the `sendAmount` How can a client distinguish between a fixed-send and fixed-receive amount payment after it is prepared and both `sendAmount` and `receiveAmount` are defined?

Since the asset code and scale should always be that of the account?