Btcpayserver: Recurring Payment Requests

[nvk]

Create an end point for seller to generate/send subscription invoices/QR email. Or better let the seller create a rudimentary scheduler to send out these invoices. If the later, could be based customer email, choose SKU and interval.

Background: Many of the Patreon users choose it because of reoccurring payments. Bitcoin is push only, so a good work around is to give the seller an option send the 'patrons' a monthly invoice with QR.

PS: didn't spend a lot of time on this, one of your contributors suggested I place my tweet/request here

Keep up the great work.

[pavlenex]

Somewhat related and can be implemented in combination with #314 .

[Kukks]

@nvk or @pavlenex Please rename to "Recurring Payment Requests" and assign to me :)

[Sjors]

Subscriptions / recurring invoices would be great for SAAS in general. For the Patreon use case, it would allow some simplification of @JeffVandrewJr's LibePatron.

I wonder what's necessary for this. Is there a (daily) cron that can be leveraged to generate new invoices where needed?

At the data model level I think a SubscriptionData object could be like this:

public class SubscriptionData
    {
        public string StoreDataId
        {
            get; set;
        }
        public StoreData StoreData
        {
            get; set;
        }

        public string Id
        {
            get; set;
        }

        public DateTimeOffset Created
        {
            get; set;
        }

        public byte[] Blob
        {
            get; set;
        }
        public string ItemCode
        {
            get;
            set;
        }
        public string OrderId
        {
            get;
            set;
        }
        public string Status
        {
            get;
            set;
        }
        public string CustomerEmail
        {
            get;
            set;
        }
        public List<InvoiceData> Invoices { get; set; }
    }

For status and exceptions, the SAAS can always inspect invidual invoices, but it's nice to have a quick way of knowing if the subscription is active.

public enum SubscriptionStatus
    {
        New, // First invoice sent, not complete
        Active, // Most recent invoice is complete
        PaymentPending, // Most recent invoice(s) incomplete (behavior is application specific),
        Cancelled
    }

Customer info gets copied into a InvoiceData object at each billing interval (the redundancy is fine, because if a customer changes their address that shouldn't impact previous invoices).

[Kukks]

This is actually not that hard to implement at all. Just been busy :)