0078 XLS-78d: Subscriptions

[xrpl365]

An updated version of this spec can be found here: XLS-78: Subscriptions.

The earlier version can be found by looking at the edit history.

[mvadari]

Isn't this usecase already solved by payment channels?

[xrpl365]

No, I don't believe it is, but happy to discuss and of course be-wrong.

[tequdev]

The main difference is that the sender only needs to set the maximum amount they are allowed to pay for a certain period of time and does not need to send additional transactions.

If we try to do this with Paychan, a very large trust is placed on the owner of the Channel's private key.

[xrpl365]

The main difference is that the sender only needs to set the maximum amount they are allowed to pay for a certain period of time and does not need to send additional transactions.

If we try to do this with Paychan, a very large trust is placed on the owner of the Channel's private key.

When i do a direct debit with my bank i don't need to have 12 months payments in my bank and certainly don't have to lock the value up.

[tequdev]

Cool suggestion!

I prefer the sfAmount in SubscriptionCreate transaction type and Subscription ledger entry to be sfSendMax. It can be understood in the same way as the current Payment transaction.

[KhaledElawadi]

Just got this ping and must say that both the idea of Direct Debit payments and the mechanism proposed is ideal for the development of other similiar related projects of which I have a few.

Will give this a good read to see what else might be useful.

Nice proposal of an essential requirement and at the protocol level too. 👏

[mvadari]

If feels very un-Web3 to me to allow someone to draw money directly from my account for a payment without me directly authorizing that interaction. I prefer the model of Checks, which are still signed by the original account, but theoretically could be issued for multiple months. This would require a minor modification to checks to allow them to be invalid before a certain time (like escrows), but I think that'd be a simpler way to go about it.

[timhoff]

It appears that I was mistaken, mvadari. The proposal does indicate that the recipient would "pull" payments. Perhaps instead of just pushing the payments in a recurring manner, the manual pull option was chosen due to the lack of Hooks on the main net. I'm a bit confused on this.

[xrpl365]

If a scheduled push payment was possible then yes, this would be automated payments and even better, but that cant be done, cus there is no ability to trigger transactions based on time events. No idea how hooks got into this conversation.

[KhaledElawadi]

Agreed, scheduled push payments would be the best way to do it and are the best way to do it and I've heard David talking about doing it too.

It's actually the basis of another proposal that I have had ever since I heard him say it live in a space.

[timhoff]

No idea how hooks got into this conversation.

Because you say that a scheduled push payment isn't currently possible. A hook could potentially facilitate that function. Alas, though...

[xrpl365]

No idea how hooks got into this conversation.

Because you say that a scheduled push payment isn't currently possible. A hook could potentially facilitate that function. Alas, though...

that was Denis that said this and he was using it in the context of a layer 2 solution.
hooks wouldn't help, they would just totally change how we implemented it, in fact we wouldn't even need this amendment if we had hooks.

[mworks-proj]

We believe this amendment is not only necessary but also transformative. It will enable SaaS platforms to utilize Web3 and XRPL for payments, offering a seamless alternative to the current model that often forces users to purchase NFTs or tokens. This feature will integrate XRPL directly into the use case, providing a more efficient and user-friendly solution for businesses and consumers alike. We are eager to help build a template to showcase this amendment and welcome any opportunities for collaboration.

…

On Fri, Aug 30, 2024 at 8:39 AM Chris Dangerfield ***@***.***> wrote: Ok, so can I get something straight in my mind. Is this an automated payment that is made from the user's account by the user or is this an authorisation that's granted to the receiver to apply for/collect X amount of funds on a certain day? The later — Reply to this email directly, view it on GitHub <#222 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASVZGDSHJXFTWMP24AEMEATZUCGZ3AVCNFSM6AAAAABNMRO2MSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANJQGA3TCNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[nrhrhysd616]

Please forgive my poor English.

In order to create a subscription, I would like to at least verify that the domain exists in the recipient account.
If a user has multiple subscriptions, this is the basis for identifying which subscription it is. Additionally, external services (such as Xaman) can verify that a subscription can be trusted when it is created.

[xrpl365]

Good point, it would definitely be a best practice to review not just the domain exists but the terms and conditions as well.

However, this is not something that affects the core, it is more something we would hope wallet providers would support.

[mvadari]

Fee Increase

• The service increases its fee and notifies the user.
• The user is prompted to cancel the current subscription and authorize a new one with the updated fee.
• To streamline this, the service could use the BATCH amendment to handle cancellation and creation in a single transaction.

Why not allow users to change the amount on the subscription instead of needing them to cancel and recreate the subscription? You could refactor SubscriptionCreate to be SubscriptionSet so you can do both with one transaction. I think there's a potential exploit opportunity otherwise, because it'd be easy to forget to set a StartTime on the recreation, at which point the service can effectively charge you twice in one month even though they just had a price increase.

[xrpl365]

Fee Increase

• The service increases its fee and notifies the user.

• The user is prompted to cancel the current subscription and authorize a new one with the updated fee.

• To streamline this, the service could use the BATCH amendment to handle cancellation and creation in a single transaction.

Why not allow users to change the amount on the subscription instead of needing them to cancel and recreate the subscription? You could refactor SubscriptionCreate to be SubscriptionSet so you can do both with one transaction. I think there's a potential exploit opportunity otherwise, because it'd be easy to forget to set a StartTime on the recreation, at which point the service can effectively charge you twice in one month even though they just had a price increase.

Yes I agree and in fact Denis and I realised this about 15 mins after posting and we already agreed that we will update the spec. But it's a really good catch and you'd only have caught it if you spent proper time considering the proposal, so for that I'm grateful.

[timhoff]

Great idea and amendment proposal, Chris and Denis. Although I'm struggling with the term, "Subscription;" which implies receiving something. I wonder if AutomaticPayment might be better?

[xrpl365]

I don't like automatic payment simply because it's not automatic, it still needs to be initiated.
It could more accurately be described as reoccurring payments, pull-payments, pre-authorised payments.
At this stage, if the name is the biggest issue you have, I'll take that happily 🤪

[timhoff]

Fair points, Chris. RecurringPayment, it is. 🤪

Upon reading the proposal again, I think that I'm more confused now than before.

Stated in the conclusion paragraph:

"enabling automated recurring payments in a secure and user-friendly manner."

This implies that the payments would be sent automatically when the NextPaymentTime is reached.

Yet, stated in the SubscriptionExecute section:

"The SubscriptionExecute transaction is used by the recipient to pull the funds from the subscriber’s account according to the predefined rules."

This sounds like the recipient needs to perform an action to "pull" the payments.

I'm seeing in the comments that others are confused whether these are pull (recipient initiated) or automated recurring payments, as well. Perhaps they are pull because of the lack of Hooks on the main net?

Lastly, it's unclear how the subscription ends, besides for the manual SubscriptionCancel transaction. Perhaps adding an endTime, or numPayments field to the Subscription object would help the system automatically cancel the subscription after the final payment has been made. Or, if no endTime or numPayments are provided, continue payments indefinitely, until manually cancelled.

[xrpl365]

Hi Tim,
I will review the wording to ensure any confusion with the word automatic is removed.
To be clear this proposal is modelled on Direct Debits which is a very common thing in the UK.
The customer authorises the service to debit their account.
The service pulls the payment from the customer account.
There are rules around it, just like in this system.
It works exceptionally well and things like cheques in the UK are all but obsolete now.

So this proposal is a pre-authorised pull payment.
The payment does not occur automatically, that is actually not possible with the XRPL, there is no mechanism to fire a transaction automatically, every tx on the xrpl has to be explicitly called, so this works no different and I see absolutely nothing wrong with this amd let me elaborate why with a practical explanation.

lets say I am the running the service.
i have 100 customers.
in my backend i know who they are, i know the subscriptionID onledger.
it isn't difficult for me to have an entirely automated payment collection system.
my backend knows then the payment is due, that's easy.
when its due i take the payment and then i deal with the response from the ledger which is either:
success - not much to do just update my records.
failure - how i do it is up to me but i will likely inform my customer and give them another chance. I will retry the payment in say 3 days and again in 7 days - and if get get a success i will update my records, else I am going to deal with the customer like i would in any normal web 2 payment workflow, which is probably terminate their service.

i could provide numerous examples of different scenarios but in my view the spec offer great flexibility and i have a couple of tweaks to make to further enhance it.

Thanks for sharing your interpretation of the wording and i will get this reviewed and updated to ensure no-one else reaches this same conclusion.

[timhoff]

Hi Chris,

I appreciate the detailed response, and understand. The difference between our perspectives, I suppose, comes from the difference between how automated payments are performed in the UK and US. Here, we can setup payments through our banks, which are either recurring or automatic, via services like Bank of America's BillPay. Instead of authorizing direct debits, payments can be scheduled. I guess in practice, this "push" approach is not so different than "pull," but it seems better to me to have the sender initiate the transaction, rather than the recipient, as it could potentially lead to higher costs for the recipient to create and maintain the required software. Concerning how the subscription ends, attached is a screenshot of my bank's BillPay setup for scheduled payments. The options for the duration are: 1. Until I stop these automatic payments. 2. Until a specified number of payments are sent (numPayments, lastAmount - if different). And 3. Until, but not after (endDate, lastAmount - if different). Perhaps these options might give you some ideas. I realize that having a transaction automatically initiated on the XRPL isn't currently possible; which is why I mentioned that a Hook could have overcame that limitation; alas. But I admit that I'm not exactly sure of what can be natively built-in to rippled. So the point might be moot. Now my mind is drifting to Axelar and EVM smart contracts.... Cheers

[tequdev]

The SubscriptionID is generated from the following elements, but the last Sequence makes it difficult to obtain a specific Subscription. By using an ID field that can identify, for example, a Plan, it is easy to see if a user is subscribed to a Subscription for a certain Plan.

Using the Sequence field could also lead to multiple subscriptions to the same plan.

• The Subscription space key (0x00??)
• The Account ID
• The Recipient ID
• The Txn Sequence

[dangell7]

Is there any scenario where one user/account would have multiple plans or multiple of the same plan?

[tequdev]

It depends on the subscription provider.
If we assume that there is only one subscription between the two accounts, then there is no need to include TxnSeq as a part of the ID.

[dangell7]

Well if there is a possibility of many, then it needs to handle many... We are assuming that there is a possibility of many.

[tequdev]

My point here is that when using TxnSeq, it is difficult to check whether one account holds a subscription to another.

By tying Plan A as Plan A = ID:1 when there are several plans and using ID instead of TxnSeq, you can search for a Subscription object from the elements Alice AccountID, Bob, AccountID, SubscriptionID(1).

Never mind what I said about the number of plans.

[dangell7]

I offered google as an initial example. With google I am billed 3 different subscriptions. Google Workspace: Gmail, Calendar, Etc. Google Voice, and a Google Hosting. Each of these has a nested plan type.

So the recipient is the same for all three, if we use a plan field then that field might need to be able to handle layers. VOICE_STANDARD or WORKSPACE_BUSINESS.

If its a VLBlob then we should just think about using sfData as the field and make it arbitrary. Though I dont really see the value in the keylet including the plan.

You can query the account_objects by recipient and then if there are multiple you can in your app filter by the sfData.

Thoughts?

[JamesTPM]

Hi @xrpl365

I tried to read everything very Carefully but here are my thoughts overall. I hope I absorbed it. I am not a developer but I hope my comments are valuable.

Details around value tied to the subscription/Refunds for value not given:

You answered this to a degree, but should the value given to the subscriber be tokenized in some way? Even if just required in the memo field of the transaction and named (EX. Chris Community Platinum Level) This would essentially tokenize and provide some account of the value the subscriber was promised.

Management of Subscriptions:

We live out life on subscriptions it seems, should we start with a better way to manage multiple subscriptions as part of the amendment?
To me as a user, I would like to see a trustline in my account representing all the subscriptions that are active. This way if I get rid of the trustline to remove the subscription.

Is there any scenario where multiple subscriptions could hit and cause issues? If there was backup or batching for example?

How does the value creator generate a list of subscribers for marketing or gain an understanding of how many active subscribers they have?

This Brings me to my next topic.

Subscription X Month Minimums.

As a creator, I want the option to lock in and incentivize 2,3, or even 6-month minimum so someone will spend the time to understand the value of something I have created. How would this be handled? In my mind to accept the transaction it would be a one time payment or hold in escrow the amount. I understand this severely complicates things but I am sure someone may want the the option.

Security and Time.
I am not sure how time is handled on the XRPL but is there any concern about vulnerabilities around time and subscriptions rapidly being taken if the ledgers understand of time was not synced for some reason?

Lending

I know this is just for subscriptions but it seems like half the solution for lending as well. At the risk of adding to the scope, could there be some additional functionality added that would allow the lending of money or would that require smart contracts?

[dangell7]

1. Yeah a "plan" field might be a good idea. Or we could use the existing sfData field and allow an arbitrary amount of data to be stored with the subscription. Memos would work just fine here too.

2. A trustline represents a bi-directional obligation. You technically are under no obligation for the subscription. It's cancel anytime.

• The SAAS provider will determine what kind of IOU they want to accept. So if you have 4 subscriptions that use USD then you can remove that trustline and then those subscriptions would end up getting cancelled when they failed to claim the funds from your account.
• Any wallet/website can list the subscriptions by querying the account_objects and filtering by subscriptions.

3. If you want to lock your user into a subscription the you should be using PaymentChannels.

4. There is a much bigger issue if the XRPL isn't making forward progress. Every single transactor using RippleTime would fail in exactly the same way. Not an issue we are solving here today.

5. Lending is covered by another XLS. I would recommend you read up on those proposals. I'm not exactly sure how you could or would use the proposals in combination but I'm sure there are use cases out there. Nothing of the sort would be added to this amendment though.

[KhaledElawadi]

So far you have talked about regular subscriptions but that is not the same as Direct Debit.

Can this proposal authorise the varying amounts requested by utility companies on an ongoing basis where there is no set amount each time?

[xrpl365]

So far you have talked about regular subscriptions but that is not the same as Direct Debit.

Can this proposal authorise the varying amounts requested by utility companies on an ongoing basis where there is no set amount each time?

Yes.
the user sets a max amount and a time period.
the service pulls any amount <= to the max amount, only once within the period.
So in your example the utility company can bill me $50 one month and $60 another month, assuming I have authorised a maxAmount high enough. With a small tweak I am going to make the maxAmount can be easily adjusted meaning no change to the rolling period but the system can then account for fluctuations in either service charge OR user usage OR any other scenario.

[xrpl365]

3. If you want to lock your user into a subscription the you should be using PaymentChannels.
   PayChannels are not a solution to this.
   If you want to avoid the users have to sign a tx every month they have to fund the channel which means having all that money then tied up. It ifs tied up, then the user is better off just making a one-off payment for say 12 months as getting a discount, which is common practice.

[Cadey]

I like this proposal, a dedicated methof agreeing that party B can pull an agreed amount from party A once per period has a lot of comercial value to the ledger.

[interc0der]

I like the proposal and I have been asking for a formal subscription service for some time now.
With that said, I am going to provide a little push back with thoughts that have not already been discussed:

1. With many proposals, including this one, it feels like there is a philosophical divergence from the original ethos of the XRP Ledger. That is - not all logic needs to live on-chain. With this proposal, are we crossing that line? Rather than an amendment, why not a company, or groups of companies, come together and offer a subscription-as-a-service?

2. New Types incur serious technical debt across all projects building on the XRP Ledger. All projects (libraries, explorers, wallets, dapps, etc.) would be asked to update implementation in order to support these new transaction models. If it brings new capabilities that cannot be achieved by other means, then it is worth the investment.

3. Have we exploring how this solution compares to PaymentChannel? It seems to me that a majority of the features within this proposal can be accomplished through payment channels. Am I wrong? I am not claiming to be an expert with PaymentChannels and I do know that people have struggled with them in the past. We should document a comprehensive comparison between both.

@dangell7 You mention ’’If you want to lock your user into a subscription then you should be using PaymentChannels.“ - Ref. What exactly do you mean by this?

[dangell7]

1. I'm not sure I understand how another company can pull funds from your account while you still retain 100% control through another mechanism? The only thing I can think of is an L2 or XpopBridge using hooks on the other side but this still sounds like you have to pay them upfront, which subscription avoids.

2. Very true, although we see this with any amendment and I'm not sure this needs to be stated. I'm sure spending time on XChainBridge only to have it deprecated wasn't fun so I do understand. I spent time on the Ledger Integration for it...

3. Yeah, the main difference between a subscription and a payment channel, outside of the fact that payment channels don't use IOU's, is that the funds are not locked in a subscription. aka the funds are not removed from your account until the recipient makes the execute call to remove them each time period.

Payment channels could be used but it wouldn't be as efficient. If I sign up for figma today, I pay every month, 15.99. With subscriptions they take that out each month. With PaymentChannels, I would need to create the payment channel for a total that I deemed. Maybe 12 months * 15.99 then I would also need to sign an authorization for them to pull 15.99 and hope and pray that they only pulled that amount 1 time per month. Thats a whole lot of trust on a trustless network. If I wanted to extend that period I would have to call a new fund transaction. Thats really not how subscriptions work in the real world...

Another example is rent and leasing. I can have a month to month agreement where they pull 1,200 out of my account each month but I don't need 12 * 1200 to be locked up and if something goes wrong I know that they cannot just claim the remaining balance before I cancel.

[interc0der]

Okay thanks for the response and the provided examples.

It seems that PaymentChannel cannot truly work for a traditional subscription service because you have to lock the funds in the channel ahead of time, relying on a great deal of trust between both parties. I need to remember, PaymentChannel was implemented specifically for micro-payments, which, while close to traditional subscriptions, departs great deal and almost breaks all conventional subscription standards.

Whereas here, you remain in control of the funds until they are pulled from your account and can cancel the agreement at anytime.

[rothexD]

does that mean an sfRecipient can pull from the wallet until its fully empty? if so, is there a need to have a minimum reserve or something similar.

[xrpl365]

does that mean an sfRecipient can pull from the wallet until its fully empty? if so, is there a need to have a minimum reserve or something similar.

Yes but the normal rules of account reserves would apply, so on the basis that the transaction would take the account into the reserves this would not complete. However this does raise an interesting question how we that.

Could do a form of partial payment or reject entirely. We will consider this.

[Tapanito]

On SubscriptionExecute transaction state changes:

Updates NextPaymentTime in the Subscription ledger entry to the NextPaymentTime plus the Frequency.

This suggests that if I do not draw on the subscription for more than one period, I will be able to execute the Execute transaction more than once, back to back?

What is the motivation for not introducing a Subscription expiration date or a total limit on the funds that can be drawn?

[xrpl365]

On SubscriptionExecute transaction state changes:

Updates NextPaymentTime in the Subscription ledger entry to the NextPaymentTime plus the Frequency.

This suggests that if I do not draw on the subscription for more than one period, I will be able to execute the Execute transaction more than once, back to back?

What is the motivation for not introducing a Subscription expiration date or a total limit on the funds that can be drawn?

Yes, you are correct.
In theory a vendor could miss the payment window without penalty and claim multiple back to back, unless we prevent this of course which we could do by using next payment date and frequency to obtain an expiration date, but I'm not sure we should be doing that.

They may do this deliberately, maybe they don't bill for a month, but they would then submit a zero value claim which is valid as that pushes on the next payment period.

An expiry date is a possibility, it would be lightweight and certainly optional but we left it out of the spec for now.

[AdriaCarrera]

Great spec @xrpl365 and @dangell7 .
Because ledger close times are not completely accurate, could a SubscriptionExecute be invalid for some validators and valid for others?
I would suggest changing the sfFrequency and sfStartTime measure unit from seconds to amount of ledgers in order to avoid it.

[dangell7]

All nodes use the same ledger time. Ledger time is also used in other amendments. I see no issue with using ledger time.

[david-esq]

Hi @xrpl365,

Great specs! Thank you for your work.
To protect the end user, we should consider making the subscription expire.
In the non-crypto world, we rely on the expiration date of credit cards (A credit card expires in the next 4 years).
We can replicate the behavior with a maximum of occurrences for a subscription (how many times can the SubscriptionExecute transaction be submitted).

Example
If a monthly subscription is caped to 12, then you subscribe for a year and must renew at the end.

In terms of implementations, it would require adding an int sfMaxOccurrences field to the Subscription object and a param to the SubscriptionCreate.

[xrpl365]

I accept your observations and indeed you are not the only person to make this point.
Not to re-iterate the point, but I think we can add an expiry and as long as it is optional I believe it would enhance the feature and add very little overhead, so I will certainly discuss with @dangell7 when we consider a revision to this proposal.

[shortthefomo]

I'm a fan of the idea.

There is one question I have though that may make it even more useful. Crypto Conditions much like that which live on an Escrow. If one adds that as a possibility to claim on SubscriptionExecute. This can allow for an automated claim framework to be build by the business executing these, instead of executing these against possibly multiple accounts.

my 2 cents, thank you for your time on this @xrpl365

[xrpl365]

I'm a fan of the idea.

There is one question I have though that may make it even more useful. Crypto Conditions much like that which live on an Escrow. If one adds that as a possibility to claim on SubscriptionExecute. This can allow for an automated claim framework to be build by the business executing these, instead of executing these against possibly multiple accounts.

my 2 cents, thank you for your time on this @xrpl365

Let's discuss this in more detail off-line and then we can bring back any findings to this thread.
I am intrigued.

[Panosmek]

I am in favor of this proposal and I think it's a very needed feature that should already been done years ago. We need to bring Web2 features, that most internet users take for granted - such as subscriptions, into XRPL.

Beyond the core subscription functionality, I believe this feature can be extended to support additional use cases, such as buying something with monthly payments or "Pay Now, Buy Later" options for merchants that accepts XRPL payments. This would provide users with more flexibility and convenience when making purchases.

However, it's important to carefully consider the implications of allowing users to cancel subscriptions at any time. While this flexibility can be beneficial in certain scenarios, it may also lead to issues, especially in real-world scenarios. For example, if a user cancels a recurring monthly payment for a product they have bought and agreed to pay monthly payments (interest could also be added in the mix if we want to make it more advanced), it could disrupt the provider's business model and potentially lead to financial losses.

To mitigate this risk, it might be necessary to implement a feature that prevents users from unilaterally canceling subscriptions under certain circumstances. This could include cases where the user has already received the full value of the product or service, or where the provider has incurred significant costs in fulfilling the subscription.

It might also be good to explore options like:

Grace periods: Allowing users to cancel subscriptions with a certain amount of advance notice.
Partial refunds: Providing partial refunds for subscriptions cancelled before the end of the subscription period.
Pro-rated billing: Charging users based on the actual time they used the service.

By carefully considering these factors, we can ensure that the subscription feature is both user-friendly and sustainable for businesses using the XRP Ledger.

[xrpl365]

Hi Panos.
First thanks for your consideration of the feature; having reviewed your comments I do agree with your points however, it is my view these types of things are not the responsibility of the protocol. If a business and a consumer enter into an agreement this should be governed by law (t&c's) as it is now in web 2, I do not think building a whole bunch of condition based functionality is necessarily the way to go. Off-chain / layer 2 solutions to your points are in my view the best solution, as it keeps the protocol change light, keeping things ultra flexible; then the business can add any logic they want on-top of the protocol.
I will discuss with @dangell7 but thank you for taking the time to add your input.

[dangell7]

A user MUST be able to cancel their subscription at any time.

https://www.ftc.gov/news-events/news/press-releases/2024/06/ftc-takes-action-against-adobe-executives-hiding-fees-preventing-consumers-easily-cancelling

[Panosmek]

@dangell7 , yes I agree for subscriptions, but in my examples I'm not talking about subscriptions. For example, let's say you buy a phone and you want to buy it with monthly payments, you have gotten the phone so, at least here in Greece, you connect it with your bank account and it automatically takes money every month no matter what because you have already gotten the device so you should pay for it and you can't cancel it.

[dangell7]

Understandable, you would want to use PayChannels with IOUs if you want to "lock" the funds. Hopefully we can get that amendment reviewed soon.

[david-esq]

@dangell7 , yes I agree for subscriptions, but in my examples I'm not talking about subscriptions. For example, let's say you buy a phone and you want to buy it with monthly payments, you have gotten the phone so, at least here in Greece, you connect it with your bank account and it automatically takes money every month no matter what because you have already gotten the device so you should pay for it and you can't cancel it.

Subscriptions and multiple installments payments are two different concepts and may not be treated with the same features. A multiple installment payments is binding and should be honored even if the payer decides to run away, contrary to an sub where the customer should be free to leave at any time, under the contract conditions.

[ralphsa]

There needs to be care taken in the design between the actual transaction i.e. debiting the account / initiating a payment and the contract that stipulates the conditions. As mentioned by @Panosmek there are a lot of edge cases where refunds etc. might occur, in most payment systems these would be separate transactions and any adjustments handled by the system that manages the subscription record.

To provide some context, in most direct debit schemes, there is a system which manages the mandate setup, drives billing etc. When setting up there is a mandate request which is lodged against the recipients account (they have to agree to this lodgement) and then there are separate transactions for each direct debit. There is also a legal framework for these types of transactions covering items such as indemnity (regardless of whether this is a card transaction or direct debit), communication of the intent to take payment (i.e. normally this has to be communicated x days before taking the payment) - this is probably beyond the scope of this and I would recommend only focussing on the actual transactions not the subscription management or other workflows in any proposal.

In the example of existing systems and direct debits, the mandate can normally be deleted from the account by the account holder, this will cause the next collection to fail. This would require a resubmission of the lodgement of the direct debit mandate before the next collection can occur.

[xrpl365]

This proposal is kind of mirrored on the UK direct debit system.
However, certain elements are not possible, for example the guarantee that exists with the UK system and underwritten by the scheme. So to protect users, this is why we have a maximum limit, essentially meaning the protocol provides the user protection, not the bank.

As regards edge-cases, I do not consider it the job of the protocol to account for things like refunds or partial claims, the protocol provides the flexibility for the business to implement these things as they see fit and ultimately it is down to the business and their customer to understand the terms of their agreement.

I appreciate you taking the time to offer your perspective.

[ralphsa]

Agreed, a lot of the existing schemes have a lot of 'non protocol' level features / implementations that are implemented through legal frameworks. So fully agree on keeping the protocol lightweight and allowing the users to agree the additional scope outside of this.

[DavidRutledge037]

This looks great! Nice work Chris and Denis.

[electromechy]

After reviewing the XLS-78d proposal and community discussions, we find this feature would be beneficial for automating recurring payments within the TextRP unified messaging platform.

Benefits:

• Automation: This feature would effectively streamline recurring premium service payments without requiring user interaction for each transaction.
• Flexibility: The ability to set maximum payment amounts and frequencies, along with the potential for future updates to adjust subscriptions, is crucial for adapting to various service models.
• User Control: We appreciate the built-in controls, such as setting maximum limits and the option to cancel subscriptions at any time, which helps maintain user trust.

Risks and Considerations:

• Complexity and Implementation: As noted, introducing new transaction types can add complexity and potential technical debt to the system. Carefully managing the development and integration of these features would mitigate unnecessary complications.
• User Trust: The potential for misunderstanding pull-based transactions in a Web3 environment underscores the need for clear communication with our users to ensure they feel secure in authorizing recurring payments.
• Subscription Lifecycle Management: We recommend considering an optional expiration date or maximum number of occurrences for subscriptions to prevent indefinite payments, which could help manage both user expectations and business operations.
• Cancellation Risks: The concern regarding users canceling subscriptions after receiving full value from a service could be addressed by implementing optional features like a minimum commitment period, or grace periods for cancellations. These mechanisms could protect businesses while still offering users flexibility and control, though don't necessarily have to be part of the transaction, and some of this functionality can be handled by the software.

TextRP supports adopting this amendment, recognizing its potential to enhance our operations by providing a more efficient and user-friendly solution for recurring payments. We are eager to see how this feature evolves and look forward to contributing to its development and/or implementation.

[rothexD]

After reviewing the XLS-78d proposal and community discussions, we find this feature would be beneficial for automating recurring payments within the TextRP unified messaging platform.

Benefits:

• Automation: This feature would effectively streamline recurring premium service payments without requiring user interaction for each transaction.

• Flexibility: The ability to set maximum payment amounts and frequencies, along with the potential for future updates to adjust subscriptions, is crucial for adapting to various service models.

• User Control: We appreciate the built-in controls, such as setting maximum limits and the option to cancel subscriptions at any time, which helps maintain user trust.

Risks and Considerations:

• Complexity and Implementation: As noted, introducing new transaction types can add complexity and potential technical debt to the system. Carefully managing the development and integration of these features would mitigate unnecessary complications.

• User Trust: The potential for misunderstanding pull-based transactions in a Web3 environment underscores the need for clear communication with our users to ensure they feel secure in authorizing recurring payments.

• Subscription Lifecycle Management: We recommend considering an optional expiration date or maximum number of occurrences for subscriptions to prevent indefinite payments, which could help manage both user expectations and business operations.

• Cancellation Risks: The concern regarding users canceling subscriptions after receiving full value from a service could be addressed by implementing optional features like a minimum commitment period, or grace periods for cancellations. These mechanisms could protect businesses while still offering users flexibility and control, though don't necessarily have to be part of the transaction, and some of this functionality can be handled by the software.

TextRP supports adopting this amendment, recognizing its potential to enhance our operations by providing a more efficient and user-friendly solution for recurring payments. We are eager to see how this feature evolves and look forward to contributing to its development and/or implementation.

A minimum doesn't make any sense i think, a minimum is just an extra hurdle. Nothing stops me from moving all of my funds to a different wallet. Effectively not allowing you to pull from my funds.

[xrpl365]

I concur with this point, very little value in adding functionality if it can be bypassed.

[XRPSezz]

I think recurring subscription payments is a good idea. The frequency of payments if no minimum limit implemented could even be daily in some instances.
A cooling off period is a legal requirement in some countries, and a customer giving notice to quit the service as well. This proposal allows for those standards to be met i assume?

I think its a sensible approach to funding web3 services.
Better in fact than anything currently available re subs elsewhere.

[xrpl365]

This proposal allows for those standards to be met i assume?
I believe the proposal is flexible enough to account for such things, but the goal of the proposal is not to enforce rules, it is to enable services to build systems on-top which are compliant in their jurisdiction.

[falila]

Maybe we can build a hook 🪝 on evernode to demonstrate this amendment.

[xrpl365]

Creating a hook to do this would certainly be possible, although the implementation would be a bit different.
However this is one of those features where i think having this baked into the protocol actually makes sense, as it is an extension to the core functionality of payments.

[xrpl365]

We believe the specification has now reached a "well-refined" state, incorporating the feedback received so far and making the necessary adjustments.
Please comment here if you have any objections to moving this specification to a DRAFT state.
We will wait for one week to accommodate any final feedback or concerns before proceeding to the next step.

(Note: Per the Contributing guidelines, moving a specification into DRAFT does not imply any formal endorsement or guarantee of adoption. It is simply a mechanism to improve the process of refining the specification.)

[Cadey]

I just have one comment, when creating a subscription i see the use of the destinationtag to represent the users external account, however i think sn explicit "text" feild ehich can be set during the subscription will help the subscription provider much more.

ExternalRef, externRef

This can be included as a memo when the subscription payment is made and can be used to solve s number of potential issues for the provider and is less restricted than the destinationTag

[xrpl365]

I appreciate the input and I will discuss with @dangell7 - the idea of a reference makes sense but whether this needs to be on-chain I am not so sure. It's a tiny change tho if we did.

[xrpl365]

This discussion has now been closed in favour of the updated spec which can be found here: XLS-0078-subscriptions