Building Recurring Payments with Stellar

keithbrink

I am planning to participate in the Stellar Build Challenge, and I am working on a recurring payment system for Stellar. I would like your feedback on my conception of how this could work.

Model #1

The user's secret key and wallet address are stored in our database. Their lumens are kept in that wallet until a request is made for a payment. Once that happens, the lumens are automatically transferred to the requestor if the user has authorized that recurring payment for that amount. Insufficient balances in the lumen wallet are handled just like a declined credit card charge.

The benefit of this model is that the user never has to remember to send lumens, which is the main benefit of recurring payment systems. The downside is the security implications of storing the user's secret key and wallet address.

Model #2

The user sends a set number of lumens to an intermediate wallet controlled by us. That wallet is charged for the recurring payments, and when the user is forecasted to run out of lumens, they are promoted to refill the wallet.

This model allows the user to control the risk they are willing to take. On the other hand, they could already do that by having a separate wallet they control themselves in model #1.

Model #3

Just build what amounts to a notification system for payments; every month, the user is prompted to send a certain number of lumens to an address. If that payment is not received within 3 days or so, it is treated like a declined payment.

This model is very easy to build but really doesn't add that much value other than making it a plug-and-play process.

rbates

When I read through this, #1 and #2 aren't that different to me personally. The logic being that I wouldn't hand over the keys to a wallet with much in it to limit my risk, nor would I fund a wallet with anything more than a 2-3 month supply that I would reload.

This is where I think consumer XLM apps need to step in and design solutions that help protect the user, while also making things simple and frictionless. Certain apps should focus on the safety, storage, and security of keys for people and their XLM, while others can focus on speed and convenience. Consumers can have multiple accounts with different use cases and risk profiles. Just like today you can carry credit, debit, gift cards, cash - and maybe you've also got a savings account, brokerage account.... and a stash of gold buried in the yard. ?

So back to your service. Before you get too far down the road you need to identify the target audience, who is the subscriber and who is the provider? You're going to need to pick something, no matter how small the audience it, in order to start the conversation with your target customer and their users. Perhaps it's for this exact site that we're all on right now. You've got a captive audience of people who are interested in Stellar, perhaps you could build a subscription model for visitors. That's just one random idea, but you get the point. You've got to focus your solution in order to get the right feedback.

Torkus

Forget about #1 due to security concerns and for your peace of mind. If your server gets hacked you're dead meat.

#2 looks like the only real possibility since #3 adds nothing and right now it's impossible to make automatic payments from Stellar unless you're the account owner and do the stuff server side. So, let's say I have to pay my monthly ~~Playboy~~ Stellar Magazine subscription with XLM but I tend to forget so I deposit ⩙100.00 in your website and you take care of making the deposit for me. Run your cron job for the day, make all payments and send friendly reminders to top up the balance when running out.

Sounds like a plan.