Actionable incoming payments

[mkurapov]

Context

Project Outline

An ASE should be able to "action" on an incoming payment: it should be able to do certain operations before it decides that an account/wallet address in question can in fact receive money.

This primarily arose out of the PCH project, as one of their requirements is that they would like to do KYC checks/account status checks before a payment is accepted. A payment should then not proceed if the checks are not successful.

What we will do is similar to the wallet_address.not_found webhook: after Rafiki sends the incoming_payment.created webhook, we will poll for whether an incoming payment is approved or cancelled by the ASE.

Tasks

• [x] Add approvedAt and cancelledAt timestamps on the incoming payment model
• [x] Add approveIncomingPayment mutation, takes in an object Input: { id: ID! } This will set the approvedAt timestamp on the incoming payment. This would only work for payments that are PENDING.
• [x] Add cancelIncomingPayment mutation, that takes in an object Input: { id: ID! }. This will set the cancelledAt timestamp on the incoming payment. This would only work for payments that are PENDING.
• [x] Add POLL_INCOMING_PAYMENT_CREATED_WEBHOOK (default false) INCOMING_PAYMENT_CREATED_POLL_TIMEOUT_MS INCOMING_PAYMENT_CREATED_POLL_FREQUENCY_MS flags to Rafiki backend.
• [x] If POLL_INCOMING_PAYMENT_CREATED_WEBHOOK enabled, do polling similar to wallet_address.not_found behaviour after the incoming payment created webhook has been sent. Wait for one of those timestamps to be set. If neither are set, return error. (maybe 400 for the Open Payments call? Something reasonable :))

[sabineschaller]

I made some comments in the doc. Let's discuss on Monday or Tuesday @mkurapov