First online payments happened before SSL was officially released and browsers could not make secure connections. A custom client had to be used to transfer the card details securely from the customer to the merchant. That was around 1994. Today 90% of online transactions in the US are card payments. The international numbers are probably lower with significant higher numbers for local, alternative payment methods. But the concept is all the same:
The customer transfers some information (card details, account numbers, etc.) to the merchant which uses a service provider (PSP) to pull money from the customer’s account through all the middle-men (acquirer, card network, banks,..) using that information. (or, in case both merchant and customer use the same wallet provider a closed loop transaction is done (for example PayPal).
To allow customers to pay with their payment option of choice merchants have to ideally integrate all options. Obviously a huge effort for the merchant. And many merchants only accept card payments leaving unserved all the people without cards. Crappy payment usability is probably still one of the main conversion killers.
Since Bitcoin we have a rather widely adopted option of transferring digital value directly between two parties. Which means we actually no longer have to transfer payment information in order to pay.
One idea that I think has too little attention is the need for better integrations of wallets into browsers.
This would allow us to move the payment method selection to the client. Imagine your bank or card provider gives you a tool to pay online. Basically a tool that understands the bitcoin payment protocol and does the transaction for you. Any company could provide their customers such a solution (possibly even with additional services like dispute mediation, insurance, etc.).
No longer the merchant decides which payment instruments their customers must have access to but the customer chooses the favorite one - as long as it can transfer value in the defined standard to the merchant.
For the merchant it will be way easier to integrate payments, no need to integrate a broad range of payment options. It comes with usability improvements for the customer.
This is not a new idea, and has probably been around since the ecash times. But with Bitcoin for the first time a increasingly, widely adopted standard for digital value exchange exists. It makes it possible to transfer “money” directly instead of some information how to access the money.
Since years there has been activities around the W3C to standardize the web payment process which would make it easier for merchants to integrate payments as well as improving the usability for customers. The whole activities has imho been/is a bit confusing with many working groups, interest groups, task forces, competing standards, etc. but probably I just know to little about the W3C works ;)
I think it is super important that the payment flows become standardized, even though it seems the focus ist still on transferring payment information.
There has been a lot of activity lately at the web payments working group which is worth following. Also very - maybe even more interesting - is the Interledger payments community group.
tl;dr: let’s move the payment method selection from the merchant’s site to the client and transfer value directly and not stupid payment information (like card details).
I am writing this from a small café in a nice little residential neighborhood. Some kids a are playing on the streets, people are passing for their evening stroll through the green avenues. Sometimes somebody stops right next to the café and screams up to the balcony next door. After a few words back and forth a small basket is let down. The person takes a bag out of it, puts some money in and walks away. Turns out, there is a women selling delicious ice cream from her apartment in the second floor to people on the street.
People are trading if we can!
And here is the thing...this happens while I am researching for possibilities to start an online business from <insert still most of the countries of this world> and market to the world. - impossible. It is still unbelievably hard for the average small business outside of maybe USA and EU to sell stuff online. incredible! in 2016! And I mean it is the internet...!
The problem is not logistics, or whatever but accepting online payments. Making it possible to transfer value from buyer to seller. Most of the time value is represented by some numbers in some databases anyway these days... so why is that so hard and preventing people from trading?!
I guess I know that global money flow is supposed to be complex and full of middlemen ;)
But It really bothers me is that it it still the main problem for individuals and small business to trade online.
We need to remove the middlemen.
Meet OpenBazaar...and Bitcoin...
OpenBazaar (docs) - is a new way to buy and sell goods and services online. By running a program on your computer, you can connect directly to other users in the OpenBazaar network and trade with them. OpenBazaar is a decentralised peer-to-peer network. It directly connects buyer and seller through the internet. Read this blog post to find more about it.
Bitcoin is used for payments between buyer and seller directly.
No middlemen preventing people from trading!
With more tools that directly connect people becoming available and usable I am confident that trading online will become more like the women selling her products from the balcony to the people on the street.
We will see more and more machines directly and autonomously interacting with each other. Machines provide services to each other that are needed to fulfill their tasks.
Many tools that we are regularly using today are already mashups relying on different services and with the rise IoT we will see only more devices consuming remote services and services directly from other devices.
Providing services obviously also involves paying for these and this is where Bitcoin comes in. Bitcoin as this decentralized, open network to transfer value allows to send value/payments directly the counterpart.
I’ve been experimenting on how this could be implemented. Here is a client and server implementation of an example for Bitcoin based API payments.
The example server is exposing an API endpoint (to lookup the weather) that requires the client to attach “some money” to its request. If no payment is attached the server responds with a BIP70 payment request and the client resends the request with the requested payment.
Here is a diagram that shows the sequence of requests:
Have a look at the README and try it yourself. What do you think?
21.co lately also released their ideas of Bitcoin-payable APIs and a marketplace for APIs running on their Bitcoin computer.
For sure something to keep an eye on.
Taiye Selasi: Don't ask where I'm from, ask where I'm a local:
How can a human being come from the concept of a "nation state"?
History is real, Cultures are real, but countries and borders are invented!
We should stop asking from which country someone is from.
I’ve been experimenting with different possibilities to integrate Bitcoin payments into applications and websites. I believe payments must become easier and bitcoin provides some great possibilities there.
In the following post looks into the Bitcoin Payment Protocol (BIP70) and shows some code for a simple server implementation (in Ruby) and a client/wallet implementation (in Java).
What is the Payment Protocol?
The Payment Protocol, described in Bitcoin Improvement Proposal 70, is a protocol for communicating between the customer’s Bitcoin wallet/client and the merchant’s server application. It greatly improves the checkout experience for the user. The user does not have to deal with bitcoin addresses but simply opens his wallet with a Payment Request from the merchant (for example by clicking on a link) the wallet gets the needed information for the payment from the merchant’s server. The user confirms the payment and the wallet notifies the server about the payment.
Besides optimizing the user experience the Payment Protocol also describes a process for refunds or exchanging additional data or notes.
Wallet implementation
I am using bitcoinj for most apps working with the bitcoin protocol. It has pretty good support for BIP70.
We will give the wallet a BIP72 bitcoin URL which contains the URL of th payment request (see server implementation). Once received we parse and validate the request. The validation is done using a X.509 certificate.
When the user has confirmed the payment we create one or more transactions to fulfull the payment request and send these back to the merchant. The merchant validates the transaction, publishes them to the Bitcoin network and sends a confirmation (ACK) back to the user.
The code might be a bit hard to read on the blog here, have a look at the BIP70 example GitHub repo. And have a look a the comments for code explanation.
Let's get to the wallet code!
wallet.java
Server implementation
Now let's look on the merchant side of things. Here I am using Ruby, but the code is pretty straight forward and should look pretty similar in your favorit language.
We basically need two endpoints:
One for generating the payment request which is requested by the wallet in the first step.
And a second one for accepting the payment and the payment ack.
Protocol buffers are used for the communication. In our example we use the gem "protocol_buffers" for parsing and generating these (have a look in the BIP for the details)
OK, let's look at the code:
server.rb
You find all sources in the GitHub repository.
Conclusion
The BIP 70 Payment Protocol improves the user experience for payments and solves the issue that the user sees who whe is paying and that he gets an immediete response from the merchant if he received the payment.
Most Bitcoin Payment Service Provides support the protocol. But experiment with it! It is easy to implement in your application/website to accept payments.
Update: btw. here is a good BIP70 introduction video
I was looking for the most simple way of tracking the places I’ve visited. (If you ask why... I guess just because...for no real reason :)
There are quite some tools out there that track your movements but most of them do that on a too detailed level and also store the location data in their (not my) databases.
At the same time I did not want to run and maintain a database myself... now what to do?
Using git/GitHub as replicable time series database
I’ve written a small script that runs every day on my computer and my phone. It gets the current location through reverse geocoding and if the city changed it makes a git commit in a GitHub repository. The GitHub API allows you to do that through a simple HTTP request (documentation) . Through the same API you can also get a JSON representation of the commits (documentation) which then works perfectly as a travel log. Every visited place becomes a git commit, human and machine readable information is stored in the commit message.
The git repo becomes kind of a time series database speaking HTTP (through the GitHub API). And as a bonus: backups are a simple git pull.
Here is the log: bumi/travels - and here a nice website for it.
I am currently in: view log on github
And here are the last cities I’ve visited (since tracking started):
Update: You can set the commit timestamp to the future to also record your next stops. To do this use the --date option on the git commit command.
Do you have a recommendation of a place I should visit? Please create an issue.
A few months ago I've built an app for my grandma. More or less the first time my skills have become directly useful for my grandma - so I am pretty happy about that. :) Our family is spread across many cities and continents and I thought it would be nice if she gets some impressions from her big family more often delivered to her house. First my plan was to get her a digital picture frame but she does not have internet and having something physical is still way nicer.
So I've built an application that allows everyone to send photos and once a certain number of photos is reached the pictures get printed and delivered to her house. Everyone simply sends in photos via e-mail and roughly once a month she gets a package of photos from all over the world.
Because I like the idea of constantly collecting some photos and getting them printed and send to myself or friends and family I made this application available for everyone:
Meet tasveer.de - tasveer literally means a picture or a photo in Hindi. (thanks to Puneet for the name) The app lets you create an album with a custom e-mail address. Simply send photos to that e-mail address and once 25 pictures are collected prints will be delivered to the configured recipients.
I am using it for myself, collecting photos on the road and getting prints automatically sent home.
The app is open source and I am planning some more features to make it as easy and seamless as possible. (The interface is currently very basic and rough - anyone wants to join and work on the UI?)
Prints are currently free because I have not yet implemented any payment options but I’d love to hear what you think. :)
I am really enjoying some of the episodes of the NPR Planet Money podcast lately. It is a twice a week podcast with just the right length easily discussing some economic topics.
Imagine you could call up a friend and say, “Meet me at the bar and tell me what’s going on with the economy.” Now imagine that’s actually a fun evening. That’s what we’re going for at Planet Money.
Here are a few very interesting episodes:
This was actually the title of a blog post written by Chris Messina in 2009. A blog post about which I have been thinking a lot last year - 2015.
The URL is the reference to a document on a computer network that tells our computers where to find a resource and the mechanism on how to retrieve it.
It is the unique identifier to any document on the internet and everyone of us is invited to create such an identifier. We do not need to ask anyone for permission. Every document that we publish on the internet has a URL.
Is the URL dead? Here are two examples that especially made me worry lately:
My young cousin and his smart phone:
My cousin got his first smart phone for his own use. He learned that to make his mobile computer useful he has to download apps from the app store. A big corporation (in his case google) decides what is good for him and what he can find in that store and buy and use. Even if he would enter a URL to some of the apps he wants to use the website only shows him logos of the big app stores - and maybe a facebook like button. Also for communicating with his friends he used the play store to download whatsapp and all his friends have to do the same. That's how he grows up.
Mobile app developers:
In the last months I have been talking and working with a lot of young developers from East Africa (but location actually does not matter). They all are excited about building mobile apps. Which is great, but it took me a while to understand that "mobile app" actually means "native android app" in most cases. Young developers grow up and learn how to build apps for a very specific platform and that they have to comply with google's terms to publish their products. And "app" also means simple content pages. This is how they learn programming.
In both examples the URL is pretty much irrelevant. These examples are very mobile focused but are true for many other cases. Read Chris' post from 2009 it is all still true.
Back in 2009 actually I did not realize the implications and honestly I have not been that worried. What I have totally missed and not thought about are all the internet new comers. All the people who now get internet access for the first time. The generation of my cousin, people in corners of the world that now get internet access, my parents or people who access the internet through other proprietary devises (like TVs or fridges), etc.
It is important how people learn to use the internet, unlearning is generally harder. Let's keep fighting for the URL.
There has been a lot of excitement in the last many years about how mobile money systems can bring financial services to previously underserved people. Mobile money systems make it possible to deliver various services at affordable costs to remote areas and groups of disadvantaged and low-income people that brick and mortar banks can not serve.
Which is pretty cool: set up a few cell phone towers, distribute some SIM cards and cheap phones, add some software and people can transact.
And on top of that it seems to be much more convenient and reliable than traditional banking services that also often lack decent mobile/online services.
M-Pesa of Safaricom in Kenya is commonly mentioned as an example of the great success of such systems. It gives people access to save money and access to loans and makes a lot of other services possible like for example the solar company m-kopa.
When I first heard about these solutions I was super excited. For me, being used to the european banking system, I was surprised how easy and well it works also for my use-cases.
You can use it everywhere - you pay everyone and for everything, from your taxi driver to your electricity meter. You hardly need to visit or interact with your bank and a big ecosystem around m-pesa has been growing.
Of course this is Kenya and Mobile Money systems are a little less adopted in other countries but pretty much all the MNOs these days operate a mobile money system. (btw. Somaliland has the highest percentage of GDP transacted through mobile phones.)
But NO those Mobile Money Systems are not exciting!
Sadly, if you think a little more about it, these systems are worse than all the things we currently know. Every carrier is its own island. Not interoperable at all. And access is controlled by one single private corporation.
It is great in the beginning to bring financial services to underserved people and optimizing distribution of help. But it is all one simple machine to create a monopoly and thus to give all the power to one single authority. And companies use their power to protect their monopoly.
We are talking about net neutrality and complaining about projects like internet.org that give selective internet access to people. But having access to financial services must be also neutral. Think of the network to transfer value. That network must be accessible for every person and every company. With minimal costs involved to participate.
Currently these systems are quite the opposite.
We need to build an Open Source Mobile Money system!
The network to transfer value must be based on open standards that make it possible to develop financial services. It must be inclusive. It must not be owned by anybody.
Everybody must be able to participate. Everybody must be able to use it and offer services.
Some of you now might say, Bitcoin (some might add Ethereum or also Stellar)! And yes, I guess that is one of the reasons why many of us are excited about Bitcoin and I am happy about the democratization this technology brings.
Bitcoin admittedly has still some flaws for directly providing the above described services. But it brought us a distributed ledger, a standardized system to record scriptable transactions in a decentralized way.
I suggest we are building an open mobile money system - a system to transfer value - on the bitcoin blockchain. Here are a few ideas:
Point is we need to an open and censorship resistant system that is not in control by a single organization and depending on the approval of that organization to integrate with the system.
Colored Coins could be a compromise to transfer assets backed by an issuer in an open decentralized network.
Further reading: