Background Hello everyone, my name is Tyler van der Hoeven. I’m the frontend developer at Baremetrics and the maker of several successful side projects. Tiny Bank , Tiny Stats and Yak Farm to name the main ones. I also run a small creative solutions studio, Tiny Anvil , building web and mobile apps. Working closely with Stripe within Baremetrics and utilizing their billing service within my various side projects is what first brought me into contact with the Stellar program. I’ve been an interested sideline member since they first launched and I’ve been actively involved in the cryptocurrency industry for about four years. Recently however, along with many many other developers, my interest has grown into action. I’ve been working on an algorithmic trading bot utilizing the Coinbase GDAX API and most recently on an idea to submit into Stellar’s build challenge. After a few months tossing ideas around and a few false starts I think I’ve finally got something I’m ready to more fully flesh out. Setting the Stage The idea is very simple, and aimed primarily as a strong proof of concept rather than a profitable business model or startup proposal. Again coming from Baremetrics where we are a subscription service ourselves and serve other subscription businesses the idea of getting paid for your service on a recurring basis is something very near and dear to my daily life. Within the subscription model you’ve got two basic structures. A traditional “subscription” wherein you sign up for a plan and pay that at simple set intervals ($35 every month, year, 12 weeks, etc.) and a usage based subscription wherein you pay for units as it were of usage. These can be time, like phone minutes, tokens, or really any arbitrary unit that you purchase and then use or burn up. Currently the former is much more popular within the tech and web industry. You pay a fixed fee per time interval and then use the service as much or as little as you like within that time. Now whether you’re aware or admit it or not both of these models are technically exactly the same. The only difference is the emphasis on either the unit or the time. In the first you're very often limited by a plan scope. Up to 100 users per month, up to 10 GB of data per hour, up to 10,000 emails sent per year. The only difference between this and charging per unit rather than per time interval is just that. The limits remain it’s just the granularity of freedom within those units or time. So for example a user on a 10 GB of data plan may only use 1 GB while another user may use all 10. Both will be charged equally. Now this in my opinion is bad for both parties. Both the service provider and the service user. It’s unfair for the provider in that what's costing them isn’t being paid for equally by actual usage and it’s unfair for the user in that they may be being billed for far more then they are actually using. Now this may eventually, in the grand scheme of things balance out but day by day and especially in the early days of a startup’s lifecycle this can be devastating to not be getting paid at a very granular level for the service you are actually providing. The reason usage based billing isn’t more popular is due to many and various factors. Far too many for me to get into now. A primary few though are: How to accurately calculate and generate usage costs. How so summarize usage costs into larger/estimable periodic bills. Calculating usage values off variable currencies. Creating and managing the backend systems to generate, send and resolve variable invoices. There are many other reasons but these are definitely a few of the key ones. All of which, as I’m sure you’re guessing by now, are solved or greatly lightened, by utilizing the Stellar network. Solving the Problem So what’s the big idea? Well the idea as I’ve said is quite simple, and there really aren’t too many moving parts. You’ve got Stellar providing a standardized token system which provides the financial platform to move the “units”, whatever those wind up being, around. My application will actually generate our own “currency” (Popcoins) as the “gas” that will move around the service as units are used in the various services that implement this service. XLMs will serve as the engine of access to the Stellar network, Popcoins will serve as the universal unit of measurement across all implemented services and the new * Stripe Connect will serve as the invoicing system to create, bill and resolve invoices. *At least for now, eventually once more popular banks federate into the system and standard currencies can be exchanged this requirement will also be filled by Stellar. That will be the day services like this one will become huge and really take off. Popcoin will be an API service that developers install into their own systems to generate variable usage costs at as micro or macro a level as they desire. For example an API developer could place calls into their system that slowly burn a users “gas” as they make calls. Some more expensive calls could cost 10 units while others could cost 1 or even fractions of units. Once a users units are all used up they receive an invoice from Popcoin requesting a refill which upon completing they may resume using the service. This could, and would actually, be a preemptive alert users receive before their units are dry, much like a car warns you when your tank is getting low, not after all the gas is already gone. The beauty of the service and the fact that both subscription models are essentially the same is you could also set your unit of burn to be time rather then direct usage. So every month burn 100 units and trigger the next invoice. You could also very easily set up automatic payments that just auto bill much like you probably do for your house rent, car lease or credit card. Variable costs at set intervals. Beautiful, and the same system. Next Steps While the idea is simple there will be quite a lot of code and design work to do. I've got people in place, it's just a matter of finding the time. I’m also curious if anyone has any great ideas or improvements or suggestions. I’m hoping to have a version ready by the July 15th deadline but if not I’ll definitely be looping back in for the October competition. So what do you guys think? Great idea or am I crazy and destined for failure? Milanote mind map of the idea Trello board of current tasks IA document API docs FAQs doc Updates [2017-06-30] Basic backend infrastructure is complete [2017-07-04] Test app is online 🍿?.ws [2017-07-06] Basic frontend design is in place [2017-07-08] Integrated backend logging, security checks and synchronization services [2017-07-11] Finished, built out and shipped the final designs [2017-07-12] Finished documentation. It's go time! [2017-07-13] Toggled to production. Officially beta ready

Popcoin – Stellar backed, usage based, billing

tyvdh

Background

Hello everyone, my name is Tyler van der Hoeven.
I’m the frontend developer at Baremetrics and the maker of several successful side projects. Tiny Bank, Tiny Stats and Yak Farm to name the main ones. I also run a small creative solutions studio, Tiny Anvil, building web and mobile apps.

Working closely with Stripe within Baremetrics and utilizing their billing service within my various side projects is what first brought me into contact with the Stellar program. I’ve been an interested sideline member since they first launched and I’ve been actively involved in the cryptocurrency industry for about four years. Recently however, along with many many other developers, my interest has grown into action. I’ve been working on an algorithmic trading bot utilizing the Coinbase GDAX API and most recently on an idea to submit into Stellar’s build challenge. After a few months tossing ideas around and a few false starts I think I’ve finally got something I’m ready to more fully flesh out.

Setting the Stage

The idea is very simple, and aimed primarily as a strong proof of concept rather than a profitable business model or startup proposal. Again coming from Baremetrics where we are a subscription service ourselves and serve other subscription businesses the idea of getting paid for your service on a recurring basis is something very near and dear to my daily life. Within the subscription model you’ve got two basic structures. A traditional “subscription” wherein you sign up for a plan and pay that at simple set intervals ($35 every month, year, 12 weeks, etc.) and a usage based subscription wherein you pay for units as it were of usage. These can be time, like phone minutes, tokens, or really any arbitrary unit that you purchase and then use or burn up.

Currently the former is much more popular within the tech and web industry. You pay a fixed fee per time interval and then use the service as much or as little as you like within that time. Now whether you’re aware or admit it or not both of these models are technically exactly the same. The only difference is the emphasis on either the unit or the time. In the first you're very often limited by a plan scope. Up to 100 users per month, up to 10 GB of data per hour, up to 10,000 emails sent per year. The only difference between this and charging per unit rather than per time interval is just that. The limits remain it’s just the granularity of freedom within those units or time. So for example a user on a 10 GB of data plan may only use 1 GB while another user may use all 10. Both will be charged equally. Now this in my opinion is bad for both parties. Both the service provider and the service user. It’s unfair for the provider in that what's costing them isn’t being paid for equally by actual usage and it’s unfair for the user in that they may be being billed for far more then they are actually using. Now this may eventually, in the grand scheme of things balance out but day by day and especially in the early days of a startup’s lifecycle this can be devastating to not be getting paid at a very granular level for the service you are actually providing.

The reason usage based billing isn’t more popular is due to many and various factors. Far too many for me to get into now. A primary few though are:

How to accurately calculate and generate usage costs.
How so summarize usage costs into larger/estimable periodic bills.
Calculating usage values off variable currencies.
Creating and managing the backend systems to generate, send and resolve variable invoices.

There are many other reasons but these are definitely a few of the key ones. All of which, as I’m sure you’re guessing by now, are solved or greatly lightened, by utilizing the Stellar network.

Solving the Problem

So what’s the big idea? Well the idea as I’ve said is quite simple, and there really aren’t too many moving parts. You’ve got Stellar providing a standardized token system which provides the financial platform to move the “units”, whatever those wind up being, around. My application will actually generate our own “currency” (Popcoins) as the “gas” that will move around the service as units are used in the various services that implement this service. XLMs will serve as the engine of access to the Stellar network, Popcoins will serve as the universal unit of measurement across all implemented services and the new *Stripe Connect will serve as the invoicing system to create, bill and resolve invoices.

*At least for now, eventually once more popular banks federate into the system and standard currencies can be exchanged this requirement will also be filled by Stellar. That will be the day services like this one will become huge and really take off.

Popcoin will be an API service that developers install into their own systems to generate variable usage costs at as micro or macro a level as they desire. For example an API developer could place calls into their system that slowly burn a users “gas” as they make calls. Some more expensive calls could cost 10 units while others could cost 1 or even fractions of units. Once a users units are all used up they receive an invoice from Popcoin requesting a refill which upon completing they may resume using the service. This could, and would actually, be a preemptive alert users receive before their units are dry, much like a car warns you when your tank is getting low, not after all the gas is already gone.

The beauty of the service and the fact that both subscription models are essentially the same is you could also set your unit of burn to be time rather then direct usage. So every month burn 100 units and trigger the next invoice. You could also very easily set up automatic payments that just auto bill much like you probably do for your house rent, car lease or credit card. Variable costs at set intervals. Beautiful, and the same system.

Next Steps

While the idea is simple there will be quite a lot of code and design work to do. I've got people in place, it's just a matter of finding the time. I’m also curious if anyone has any great ideas or improvements or suggestions. I’m hoping to have a version ready by the July 15th deadline but if not I’ll definitely be looping back in for the October competition.

So what do you guys think? Great idea or am I crazy and destined for failure?

Milanote mind map of the idea
Trello board of current tasks
IA document
API docs
FAQs doc

Updates

[2017-06-30] Basic backend infrastructure is complete
[2017-07-04] Test app is online 🍿?.ws
[2017-07-06] Basic frontend design is in place
[2017-07-08] Integrated backend logging, security checks and synchronization services
[2017-07-11] Finished, built out and shipped the final designs
[2017-07-12] Finished documentation. It's go time!
[2017-07-13] Toggled to production. Officially beta ready

sacarlson

Sound like what we heard could be done some time back but have never seen it implemented. A plugin for a micro payments system to what ever service that can make use of it. I assume this would be good for example to implement on like a Wifi or small internet system that wouldn't even require each access point to be connected to the same firm to run it in any way to still get money for there service. so in that way you could have seamless connection to Wifi Internet from many unrelated points.

I think more examples of this systems usage is needed to get a better idea of what it is your trying to create might help. Or verify that I am on the correct page with my thoughts above on this.

Also I'm not sure about the stripe part. Seems to me the bridge to fiat to pay for the popcoin can be done with the infrastructure we already have or are creating in stellar.org. you simply need to have some set value that you peg popcoin to that you setup to auto sell on the stellar.org market with bots to keep it the value that you want it to be. At least this would be one option to start. With this method you can focus on one section of your infrastructure at a time.

But I guess stripe would come in if you want to setup a store to sell your popcoin units to be used to recharge services. There like you said you could also add periodic payments and such.

In any case the whole thing from the users perspective has to look to be simple to charge up. Much like when you pay for services like skype to make calls. you would want a site the allows purchase of your popcoin recharge whether it uses anchors we already have or you setting up of your own.

tyvdh

sacarlson Yes kinda. I think you're missing it a little though. Also as far as I know there are very few, nearly no, banks that will allow you to directly transact with them. So currencies you hold within the Stellar network can only be used within that network. That simply won't work for 99% of all users. They will want and need money in their native currency (USD, EUR, GBP) to be actively moving into their bank accounts. Until banks allow this we're stuck using an intermediary third party like Stripe Connect.

Also the whole XLM, Popcoin nature of the service will be behind the scenes. Neither developers using this service or their users will need to be aware or concerned that Stellar is running things in the background. All they'll know is that they use a call like Popcoin.burn(1, 'user_id_abc123') within their codebase and as that method gets called eventually an invoice will be sent to user_id_abc123 and from that they'll get money into their bank account.

As far as use cases the possibilities really are endless. My main use case is billing for API usage but I also see:

Charging for online educational material
Renting out virtual machines (think Paperspace)
Paying for movie screentime
Premium blogs and articles
Traditional monthly subscriptions which can fluctuate naturally without a ridged plan structure
House, car, etc. rent services

There are obviously many more use cases but really anything you could identify individual users and units of usage could be a potential candidate.

pacngfar

Very good idea, but I am wondering how do your decrease balances and guarantee that users have enough coins to use the service ?

Let's take the example of a pay-per-call API service that costs 1 Popcoin per call. How do you decrease the user balance at each call ? Do you keep your users stellar account and private keys and decrease at each time ?

Or you let users keep their privates and find a way to authorize a call ?
This would be feasible but painful:

Ask service for a temporary API key
Service return a stellar address and memo to send coins to, and an API key
User pay and call the API with the API key

This process make an API call very long

tyvdh

pacngfar Great feedback and actually something I've already run into and worked through. The only Stellar accounts that Popcoin will create and maintain are the developer accounts. Those developer accounts will communicate directly with users across a available/current balance system outside of the Stellar network. Then periodically the differences will be balanced from the developer account and the Popcoin service. Think of the system like a gas station. Popcoin is the oil company delivering gas to the station or developer. They station then sells and fills up cars or users with gas. The Stellar transactions are only between the developer and the Popcoin service. Everything else is just a realtime running invoice between users and the developer's service that balances periodically within the Stellar service. This limits the number of Stellar accounts I have to fund and ensures API calls to my service are quick.

Hopefully that all makes sense. ?

tyvdh

Here are some preliminary designs to help flesh out the idea a bit. The design is all under active development currently via my good buddy Jordan .

Home Page

Account Page

Invoice Page

Invoice Email

So from those, what else would you all like to see? Any suggestions or settings you guys think are essential?

tyvdh

New designs are coming in!

bkolobara

Love it!

pacngfar

Really really good!

So just to make sure I have well understood the system:
Let's say I wanna make a paid API service. Everycall that my user send to me, I send a burn call to popcoin to verify this user has enough gas before running my service ?

tyvdh

pacngfar That's exactly right. There are obviously other use cases than a paid API service but that's definitely what I'm aiming for as my bread and butter.

tyvdh

Here's the redesigned account page

And an example invoice email

And finally an example invoice page

lumag

Is there any provision for accounting available through the API? As in when some of the credits are burned a record is made showing when, why and how many credits were burned in that transaction. This may be needed by some business customers.

tyvdh

lumag As of right now no. However that is a great suggestion and would be good to have just for logging and debugging anyway. Adding to the roadmap. Thanks!

tyvdh

As of today if anyone is ready to try it out the app has been toggled to production and is ready for beta users! Let's get you paid.

Please leave any and all feature requests, feedback and bug reports here. Would love to keep this conversation going.

tyvdh

Popcoin isn’t even out yet and folks are already raving! https://popcoin.ws/quotes

dzham

Looks good!

Is it using payment channels? Seems like a perfect use case for that, otherwise you're just going to end up spamming the Stellar network with small value payments :/

Website is down, BTW

tyvdh

dzham Whoa! Hadn't ever heard of channels. Definitely implementing this. Thanks for the suggestion. Site should be up now too. Sorry about that.

tyvdh

For anyone who has signed up recently and been unable to connect or create their Stripe account, we've just expanded the country support in Stripe Connect. https://popcoin.ws/

mazieres

What is the intended sequencing of burning coins and providing service? There doesn't seem to be any distinction between authorization and charging. Is the idea that service providers assume a small risk of users running out of popcoin? That might actually be a viable trade in exchange for not having the possibility of chargebacks, but it would be good to spell it out in more details so that the corner cases are clearer.

tyvdh

mazieres Not sure I understand the question. There's definitely a possibility that users will run out of coins but it's up to the developer to decide what that means. Popcoin will just return a 402 if the balance has been depleated. You can then block usage of your app, make a note and alter the experience or just keep going on as if nothing happened. Popcoin will send invoice reminders periodically as long as the account is depleated or below the threshold.

Not sure that answers the question though. ?