Recurring Payments

[olanod]

I was initially thinking of doing it as a separate pallet but I think it can perfectly fit the scope of payments pallet to introduce a pay_recurrent extrinsic that allows payments to be created automatically based on a schedule that specifies how often the payment is and when(if) it stops.
Unlike a vested transfer the origin account is not required to have all the funds since the the end period could be undefined(infinite funds?) but maybe the payer should have at least X times the amount of one payment(e.g. 3 and we could always reserve the amount for the next payment besides the one in progress 🤔).
Also I don't think we need to schedule all the payments but only the next one after a successful release, say I do a pay_recurrent with a period of 100 blocks the first payment is immediately dispatched(reserved on the destination as usual), ideally is released quickly as the payee should have completed the service/sent the product but in case it hasn't and takes long(i.e. more than 100 blocks) to fulfill the payer requirements for a release then no new payment is made. Releasing within the period shouldn't alter the schedule though.

[stanly-johnson]

How about we do this in a separate pallet that will act as a wrapper for the scheduler pallet? So pay_recurrent, will do some checks on the payment and then create a schedule_named task.

Or we could add the scheduler pallet and let the frontend construct the call manually 🤔 Wdyt?

[olanod]

It can be a separate pallet and we could use scheduler pallet, some reasons I think it's worth adding it in the payments pallet(under a feature flag and all implemented in a separate file?) is that feature/product wise it is very related to the existing logic and expectations of the payments pallet, having a pay and pay_recurrent with only the addition of the schedule is something users can easily reason about instead of expecting them to know there's another pallet. It would not be an uncommon thing to pay e.g. for a service and later switch to a longer term commitment with pay_recurrent, also on the development side is less moving pieces and less repositories to maintain and potentially integrate upstream in ORML.

About the scheduler pallet we could depend directly on that, what I don't see that convenient(but should be doable with schedule_named) is to support the feature I mention about not scheduling and releasing further payments until the ongoing one is released. For example if a treasury is paying a team to deliver a set of milestones, the first payment is made, assets arrive and are locked(, optionally they could borrow a liquid derivative with the locked assets as collateral), ideally the next payment is in a month for example but if the team hasn't delivered the first milestone the treasury doesn't release the funds yet and the next payment doesn't happen, once they deliver with a delay the funds are released and the next payment is made moving the schedule. ... or(just brainstorming on the go 🤔) it's my assumption moving the schedule is desirable since it also means there can only be one payment at a time per payer/recipient but maybe it's not so desirable, which is simpler on the scheduling side since we can use the scheduler pallet scheduling the whole period and the payments are made exactly when scheduled, it will be up to the treasury in this example to release each payment separately once they consider each milestone to be delivered, this also means we would likely need to implement "multiple payments" to allow more than one payment per payer/recipient(which is a desirable feature I guess?)