Contract/subscriptions

[ghost]

Description

This contract enables subscription-based models, including pay per /minute/hour/day/week/month. Subscription-based models are very often missing in blockchain or very limited. The subscription contract proposed here enables a great variety of use cases, including:

• Sending recurring payments to one or more individuals/platforms
• Receiving payments from the subscribers and split them to one or more beneficiaries (See Patreon)

Operations

addAuthorization

This action is necessary in order for the subscription to pay the installments. The contract must be authorized to move the funds. Each authorization is linked to a contract, a specific version of the contract and the action that performs the transfer. The subscriber (the account paying the subscription installments) will have to submit the following custom_json operation, signed with the active key.

{ "contractName":"tokens", "contractAction":"addAuthorization", "contractPayload":{ "contract":"subscriptions", "version":2, "symbol": "ELEARDEV", "action": "installment", "type": "transfer" } }

• contract The name of the contract that is getting the authorization, in this case: subscriptions
• version The version of the contract
• symbol The name of the token the contract will be authorized to transfer
• action The name of the action the contract will receive to transfer the funds
• type The type of action the contract can do, in this case: transfer

subscribe

The subscriber is the account submitting the custom_json operation below (subscribe action), signed with the active key. The following operation will enable the provider to request the payment of the subscription installments. The provider will be enabled to move the quantity of symbol tokens for the defined period that recurs every recur for a maximum of max installments. The beneficiaries get a percentage of the quantity based on the defined percent param.

In the below example, elear.dev will be able to request from the subscriber 100 ELEARDEV every 5 minutes, to be sent 50% to elear.dev and 50% to harpagon, for a max of 10 installments.

{ "contractName":"subscriptions", "contractAction":"subscribe", "contractPayload":{ "provider":"elear.dev", "beneficiaries":[ { "account":"elear.dev", "percent":5000 }, { "account":"harpagon", "percent":5000 } ], "quantity":"100", "symbol":"ELEARDEV", "period":"min", "recur":5, "max":10 } }

• provider The account authorized to request the payment of the installments
• beneficiaries The beneficiaries of the installment. It can include the provider, cannot include the subscriber. The percentage must be in total 10000 (equal to 100%) and can never exceed 10000. The max number of beneficiaries is 8.
• quantity The number of tokens each installment will pay
• period min/hour/day/week/month
• recur When the installment recurs based on the period. In this example every 5 minutes
• max The max number of installments this subscription will ever pay

The custom_json operation will return the ID of the transaction. The provider should keep track of the transaction ID to request the payment of the installments via the installment action below. The subscriber should keep track of the ID in the case he will want to unsubscribe (see unsubscribe action below).

Note: The subscribe action does not move funds and does not check if the requested funds are available. The first installment will be paid when the provider submits the first installment action, as detailed below.

installment

This operation can only be submitted by the provider, to be signed with the active key. The provider should submit the custom_json operation based on the subscription period and recur params. For example, if the subscription should be paid every 5 minutes, the provider should submit the custom_json operation every 5 minutes (as long as the minimum time has passed since the last paid installment, the new installment action doesn't have to be submitted exactly after 5 minutes, this is to give to the provider some margin of time to submit the installment actions in the chain). The subscription contract will take care of verifying if the installment is payable as it was agreed in the subscription params.

{ "contractName":"subscriptions", "contractAction":"installment", "contractPayload":{ "id":"7315ead41d2d2f23fc3e570aa4ab3edac57d1c28" } }

• id The transaction ID of the custom_json operation that was submitted by the subscriber to initiate the subscription (see the subscribe action above).

Note: The installment may not be processed if the subscriber does not have the necessary funds or if the subscriber unsubscribed (see unsubscribe action below). It is up to the provider to check whether the installment was paid and received by the beneficiaries as described in the subscription params.

unsubscribe

The subscriber can submit this operation, signed with the active key, to immediately remove a subscription and stop its installments.

{"contractName":"subscriptions","contractAction":"unsubscribe","contractPayload":{"id": "7315ead41d2d2f23fc3e570aa4ab3edac57d1c28"}}

• id The transaction ID of the custom_json operation that was submitted by the subscriber to initiate the subscription (see the subscribe action above).

removeAuthorization

This action enables the subscriber to remove the authorization to move funds from the contract. This action is triggered internally also once the subscription is either fully paid or canceled (see unsubscribe action above).

{ "contractName":"tokens", "contractAction":"removeAuthorization", "contractPayload":{ "contract":"subscriptions", "version":2, "symbol": "ELEARDEV", "action": "installment", "type": "transfer" } }

[ghost]

There was a merge error, which is now fixed. All the tests are running properly. Lmk

[octalmage]

This is wild! Never seen anything like this on a blockchain.

[Vheissu]

This is awesome. What is left to get this merged in @harpagon210 because this is a huge addition.