ESI Bills, Feature Request

Hey,

So you can’t charge RL money for your application but you can however charge isk but you cannot automatically take payments from accounts, quite rightly so.

Here comes my idea, wouldn’t it be good if there was a way to setup “direct debits” between users that the ESI can trigger. Recurring automated monthly payments. These could also be used by renters and anyone else that sells things based on subscription via in game settings but the main motive behind it is to allow developers to charge isk subscriptions in a safe manner for the dev and the user.

Using the already available UI end points the dev can prompt the user to create a “direct debit” giving the amount and the frequency of the payments as well as outlining where the ISK will be paid. The user can also find and cancel these on another screen however the key being the ESI then gets an endpoint to trigger this getting a status back. This would allow the game to only allow a success when it should do an reject the request all the other times. This would allow developers to request the money and update subscript status automatically and if the transfer fails the service can be cancelled, much like in game mechanics.

Try here: https://github.com/esi/esi-issues

this seems more like a features and ideas type thing. if this feature existed in game, ESI could expose the data…

I do think the idea’s good though, it has merit and multiple use cases, but it’s not really appropriate for ESI-issues

Can it be moved to some where more appropriate then ?

My apologies it felt more like a ESI request than a full in game feature, at least that was my approach to thinking about it but it does make sense that it could be setup for in game use as well.

images

Easily enough to do with the current system. If you charge monthly, just have the software use a dedicated character to send people mails with 7 days remaining saying “dont forget to pay for next month.” Use that character’s wallet to detect subscription payments. They dont pay? Disable their app account or something.

Tying an application to a particular character seems clunky and inflexible for the use cases described. When you get a power bill, gas bill, whatever bill, you don’t send it to the CEO of the company the bill came from. The ‘direct debit’ method seems to be the most appropriate means of limiting the number of identities involved to a transaction. Office space rentals are able to be automatically deducted, why not application access? At least this method has an additional protection over office space rentals from the cost being ramped up without notice by consenting to a fixed amount beforehand.

Use that character in a 1 man corp then. The options are there. While I agree there should be something like this available overall for eve, for us 3P devs, I dont see there being much difference between how we would act upon a transaction completion through someone sending an entity of your choice isk directly, and how we would act upon someone paying a “bill.”

When ISK is sent from one entity to another it is recorded as a ‘Player Donation’ even though it could be for multiple purposes, hence the ‘comment’ field. When CCP controlled entities issue bills, such as CONCORD bounties or the SCC market taxes it is recorded as one of the many ‘Bill’ types.

A 3rd party application that charges ISK for a service isn’t soliciting donations, its issuing a ‘Bill’. This is a much more consistent type identifier. It would additionally be cleaner to iterate on “Bill” types than iterate on “Player Donations” and have to regex through the ‘comment’ field, if present, to determine if a transaction is of interest.

The point was more to make it easier for both parties. As you say it makes it easier from a 3rd party point of view because its one call to check if you can pay or not and its automated so that players don’t have to remember to pay for it. We all know what happens when people forget to pay bills…

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.