Ask a Question

Include outgoing payment `/authorize` endpoint?

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).

Should we include `createdAt`

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

Re-quote authorization

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

Async vs Sync when creating outgoing payments

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?

Should list endpoint pagination be defined?

for listing incoming and outgoing payments

incoming payment incomingAmount should be optional

to allow for the web monetization use case.

incomingAmount on create incoming payment

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

Could outgoing payment's receiveAmount be changed to deliverAmount?

To make the perspective from the sender.

Distinguishing prepared fixed-send vs fixed-receive amount payments

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?

Can outgoing payment sendAmount be an integer?

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