EDIT: 2015–09–22 — I noticed I didn’t specify one crucial point, which is that 100% of all micro-payments will be transferred to the desired recipient. Micropay.Rocks will simply be another client on the platform whom users can decide if they’d like to send micropayments to. I intend for this service to simply be a conduit through which people can transfer money to one another, with no mandatory “middle man” compensation.
EDIT: 2015–09–23 — I have been thinking a lot about transparency, and how I can utilize that to begin to gain trust in the “micropayment” community (if such a community exists). I have decided that from the get-go, I will make public all funds donated to the project on a monthly basis. That’s not to say I’ll specify who is donating how much. This way people can use their best judgment as to whether or not they should feel compelled to help support the project. And once I figure out what kind of expenses are necessary to sustain this project I’ll make that public as well. I intend to do everything in my power to make this project as transparent and fair as possible.
EDIT: 2015–09–23 — It will be policy of this project to never disclose who is donating what to whom.
Micropay.Rocks is a new micropayment platform I’ve been working on over the last several weeks. I really only have a few final things I’m contemplating before rolling a version of this out for people to use. So I thought this is as good a time as any to start getting feedback. Especially since I’ve seen that quite a bit of conversation is happening on Twitter and in other places with regard to micropayments’ place in the online ecosystem. With Apple putting features into its products to make it easier for users to block online ads, it has alot of people wondering how they’re going to be able to convert their online presence / efforts into something sustainable. I was originally going to make this in the form of a screencast, but after a few failed attempts (maybe I was too critical of the end product) I decided to convert this into a blog post.
PS. If possible please don’t visit the site just yet (September 21, 2015). I’m running everything on a single Micro instance on AWS, so depending on the kind of attention this receives you could very easily find that the site will be inaccessible. Also currently the live version of the site is still connected on the backend to Dwolla’s “test” servers. The screenshots I’ll be providing here should be sufficient to get the idea. In order to get more up-to-date information I’ve set up a Twitter account @micropayrocks. This is where you can find the most recent information about this project (not much there at the moment).
There is one important high level assumption I used as inspiration for the design of this system. As the web continues to grow at unprecedented speed, our connections and access to information is growing at a rapid clip as well. With this, the need to be able to deal with all of those connections, and all of that information in an efficient way becomes more and more critical. I doubt alot of people really try to avoid the idea of micropayments. Instead I think alot of the lack of traction has come from some basic difficulties in managing large numbers of micro donations simultaneously. I hope I’ve been able to capture some ideas within the following project which will help reduce friction and encourage wide spread adoption where it becomes common for people to be making monthly micropayments to 100's if not 1000's of projects / people all across the web.
When you first visit the website you’ll be presented with a very simple almost “no-design” concept. Obviously I’ve drawn some inspiration from Hacker News (news.ycombinator.com). There’s a placeholder for a screencast which I’ll use to onboard new users to explain how the site works and perhaps add a link to a wiki for additional documentation, but nothing fancy. In the top right is the “login” icon.
Currently the site is tied into Dwolla’s payment system. Some of the reasons for this are: (1) They have no-cost transfers for even small [micro] amounts, and (2) The API is friendly and easy to use. While it’s not going to happen immediately I’m certainly open to adding other payment platforms as I learn about them and find that they are a good match for what I’m trying to accomplish. The one real downside is that Dwolla (at least at the moment) is not international, so as things stand this is going to be US-only for the near term. It’s a shame we don’t get free international transfers, but I can certainly imagine a future where this could become a reality. It appears Dwolla is open to it, but have not seen enough interest internationally apparently to warrant investing the time / effort.
After I’ve allowed access to these permissions, I’m presented with a basic menu of options:
The menu is broken into 2 sections: (1) Donations, and (2) Projects. This represents the “roles” that a user may need to manage. First, a user needs to have a set of tools to manage the donations they are making to other projects, and on the other hand they also need a set of tools to manage the projects they’ll be soliciting donations for.
The Account screen gives me some basic options for my account as a donor. (a) Monthly Contribution: How much money do I want to donate across all of my selected projects every month, (b) What day of the month do I want my donations to be processed, (c) What is my timezone [helpful to ensure timely delivery of email notifications] (d) What email address should the system use to communicate with you
The “Monthly Contribution” field brings me to an important premise that I’m basing this system on. You’ll read more about later in this post, but for now it’s important to understand that within this system, as a donor I won’t be overwhelmed with all the busy work that can be associated with managing donations across many projects / people. I want to choose a single amount that I’m personally comfortable with. This way no matter how many additional projects I decide I want to start making monthly donations to, I don’t have to continually re-adjust the amounts across projects. I can rest assured knowing that my account will only ever be deducted the monthly amount, and the system will automatically re-allocate funds across those projects for me.
Providing this dynamic recalibration I think has the potential to remove alot of the friction that may be preventing microdonations from growing at a faster pace.
Funding Src Screen
This is tied into Dwolla. As you add more funding sources to your Dwolla account you will see them reflected in this dropdown. This is how you can (a) decide which funding source to use for your donations, or (b) temporarily stop making donations or disable the account. Without a Funding Source defined, the system will not make donations on your behalf.
So you may have been wondering “If I’m going to allocate a flat amount each month, what if I want to give more to one project over another? Tiers is the answer. You can think of this simply as a way to build an arbitrary list of categories that you will use to “tag” the projects you donate to. In the above screenshot I’ve (blandly) defined my tiers “Pay less” and “Pay more”. You see also an arbitrary weight that I’ve attached to each tier (10 = Pay less, 20 = Pay more). Just to give you an idea of how the system calculates, it’s all based relative to how much a given tier is weighted compared to the next, and also relative to how many total projects (ie. total weight across all projects) you’re donating to.
So as a quick example, suppose I’m donating to 2 projects in the “Pay less” tier, and 1 project in the “Pay more” tier. If I’m donating $100 monthly, this means I pay $50/mo to the 1 “Pay more” project, and $25/mo each to the 2 “Pay less” projects.
But that’s a very basic example. As you add more and more projects it could easily become difficult to know exactly how funds are being distributed across your donations. That’s why I’ve created the next screen I’ll talk about “Dry Run”.
Dry Run Screen
Notice how the Dry Run screen shows a list of 2 projects. In this test account I am making monthly donations of $100/mo. And so as you see, based on the previous screen’s weights, I’m set to pay $33.33/mo to the project I’ve tagged with the “Pay less” designation, and $66.67 to the project I’ve tagged with the “Pay more” designation.
My Donations Screen
On this page I also see my list of “Current Donations” along with a few tools. (1) The finger pointing left, this allows me to change the tier designation of my projects. Just select the tier from the dropdown at the top of the list, and for all projects you wish to change the designation, just click the finger pointing at the project you wish to change.
The next icon you’ve seen in previous screenshots above. It’s there to allow you to “preview” the project landing page (we’ll get to that in more detail in a minute). For now you should know that for all projects you may want to donate to, the “project owner” will redirect you to a “project info page”, hosted by this site, with options for how you can donate to the project. As you continue to add more projects it’s likely you can forget or lose track of which project is which. In order to give yourself the context you need in order to know how to manage a given project, you can pop open a new window to view the project info page to review all the specific details about the project you’re donating to.
And finally, the ‘X’ allows you to delete the record, which will stop all future monthly donations to that project.
Here’s an example of the page you’ll see when clicking the “preview” icon in the list above:
Landing Page (preview mode)
This will basically be where you can review a summary of past account activity. You should also have this kind of information available in your Dwolla account, but just to ensure appropriate information is retained, we’ll keep a copy of past donations here as well.
Now that we’ve seen the screens available for managing your account based on your role as a “donor”, let’s have a look at the relevant screens which will allow you to manage the account based on your role as a “project owner”, for projects that you wish to solicit donations for.
One of the critical elements of any micropayment platform is to ensure it’s not easy for people to scam the system. For this I’ve integrated OAuth with a handful of popular providers: Facebook, Github, Meetup, and Twitter. Basically from this screen, in order to link a social media account (assuming it’s affiliated with one of the projects you’re working on) you click one of the 4 links under the “Initiate OAuth” header. When that happens you will initiate an OAuth handshake with the applicable provider. After you have been redirected back to the site, the social media network will have passed enough information back to the app so as to ensure you’ve authenticated that social media account. The reason you do this is for when you are creating / updating your Projects from the “My Projects” screen next. You can add as many “Facebook” or “Twitter” social media accounts, but have a restriction that each project can only attach one account from each of the social networks.
My Projects Screen
Here you see a list of your projects that you have previously created and can now manage by clicking on the project name. (below)
My Projects Screen (expanded)
Here you see a zoomed out view of the entire form you would use to add to or edit your list of projects. The one form field that might not appear self-explanatory in the screenshot above is the “Redirect URL” field. This is used to dynamically generate a URL you can embed in your own pages in order to ensure that a user gets redirected back to your site (or a particular thank you page) after they have made a donation to your project. You can generate a URL by typing in the first of the two text boxes. You would type the URL of the web page you want the user to be redirected to AFTER the donation transaction has completed. The remainder of the URL will be populated (along with your redirect info) in the second of the two text boxes. So this output in the 2nd of the 2 text boxes is what you would embed in the “href” attribute of your link or button you embedded into your project page. For example:
Here’s a screenshot of a hypothetical “simple” website where I’m inviting a user donate to my project:
When the user clicks the ‘Donate’ button above they will be directed to the “LIVE” version of the project info landing page (Note the absence of the orange “Preview Mode” banner at the top).
Landing Page (live mode)
Once a user has made their donation they will be automatically directed back to the URL you specified in the “Redirect URL” section of the form you used for managing your project. NOTE: unless you’ve linked a pre-auth’d social media account to the project, the link will not show up on the bottom under the title “Authenticated Social Media Links”.
I’ve also considered the situation where a user may not be logged into this system. If that’s the case, and they were directed to the donation page, they would be redirected to the Home screen where they would be prompted to login. Once they were logged in, they would be redirected back to the applicable project info page, and then of course after they made their donation they would be redirected back to the site you specifed in the “Redirect URL” section when generating that URL.
Thank you for taking the time to learn about my project. If you have any feedback I’d love to hear it. I’ve only spent a few weeks on this so far, and already I have a ton of ideas that I think would be useful and fun to implement. Also if you can suggest payment platforms that might be easy to integrate into this (so I’m not 100% dependent on Dwolla [ie. international], but have the same benefits as Dwolla) I’d love to hear about that also.