Discussion: Allow subscriptions against an avatar's L$ account

I would like to propose a service, to be provided and managed by LL, that would provide a merchant the ability to bill an avatar on a subscription basis. For example, if I sold an ongoing service and would like to charge L$100/week for the priviledge of having my service I could request a subscription from the user. The client would provide them the terms of the subscription (configurable by the merchant) and would register a subscription with the SL servers. Once a week (maybe Stipend Day?) the server would look through an avatar's subscriptions and make payment on them from the avatar's L$ balance. Merchants whose subscription prices could not be met would be notified. These subscriptions could be managed from the My Account webpage at secondlife.com and could be cancelled, extended, et cetera by the avatar and reports could be provided for merchants.

What do you all think? I know that similar functionality could now be accomplished by a private party using scripted objects, but I'd like to see it in LL's hands for the sake of consumer safety and simplicity.

you can already do this with a box and PERMISSION_DEBIT

Hmm, while that is true, I still like the original idea, as a script isn't trustworthy, you don't know what it's doing or when it's going to charge you, it's also possible that you might not be able to then cancel the subscription, though I suppose you can delete the object (debit can only be requested from users owning the object iirc?). However that raises the next potential abuse of someone deleting the debit object.

With a subscription system at least you would be guaranteed that with it being done via the system that it will be more trustworthy and can cancel at any time.

How would it be implemented? Perhaps a simulator level thing so that it can be tied to an object, ie object A gives user B a subscription. Every week the simulator requests money from user B and pays it "into" object A (or the user owning it rather), if object A is no longer there to pay money into it goes back (or is never requested in the first place).
This way it's on the object level, so if the user cancels the subscription it could go via the object as a subscription_end() event or such, and it could also end the subscription when required (e.g 5 easy installments of L$100)

if they delete the debit object the "server" you own will not receive the confirmation of the next payment. Of course just a box that pay aint gonna do it, you need something a little higher level than that.

Well, the subscription would still be held somewhere more central, but it would go via the simulator where it was registered (ie a moving object will lose it's subscription) as that appears to be the only way to reliably do something via an object which I think is how a subscription system should really be done. Especially for any kind of automation.

So basically when the subscription begins, a note of it is stored somewhere along with the simulator's key/name so that payments can then be handed off to the simulator.