A few months ago, we at SatoshiPay launched our first public field test, a.k.a. “beta”. We started by releasing a WordPress plugin and got some great feedback from around the globe, so now it’s time for making our technology available to every website, no matter what back-end it runs on.
We are doing this by opening up our API to third parties (see press release). Read about how our system works and how it can be integrated in the API documentation. Using our API, developers of content management systems can write their own plugins and publishers can integrate nanopayments into their own bespoke back-end. With a bit of playing around, HTML coding folks can even sell content on static websites.
Throw these two tags into any website and you are selling a text snippet, with a price of less than a cent:
This will be displayed on the website:
After you paid, this will be shown in the exact same spot:
See this example on a demo page. For real-world content pick a review at Incorporating Bitcoin or read an article by our investor Jim Mellon published by Master Investor. Send us your links, so we can feature them here!
Nanopayments: A thousand times smaller than micropayments, who needs this?
Micropayments are generally defined as payments of €10 / $10 or below. Nanopayments can be fractions of a cent and were not possible in open-loop systems before cryptocurrencies emerged. It was minimum fees of at least 10c per transaction that previously prohibited sending 1c over the internet using a payment provider. Now with this barrier removed, entirely new business models based on the rapid succession of nanopayments become possible.
We are currently offering our system to allow content providers to unbundle their content and offer it in small increments. But thinking beyond content and making our system bidirectional is what will keep us busy in the future. Ultimately, we want to supply a generic infrastructure for nanopayments, so you don’t have to. Focus on great content, digital goods and applications and we will cover your back.
HTTP 402: Payment Required
Already in 1996, in the first versions of the core internet protocol HTTP a status code for payments was “reserved for later use”. It was never specified further and before Bitcoin there were no implementations. Now with one decentralised technology (the web) meeting another (cryptocurrencies) some work was done by 21 Inc, Casey Leonard, a project called ZeroClick and the W3C Web Payments group. Implementations differ and it’s a good moment to develop a standard. In the HTTP 402 section of our documentation we proposed some standards that we would like to discuss with other vendors and developers. Please contact us if you have some input on this.
How It Works
What makes all this possible is a protocol on top of Bitcoin called Micropayment Channel. It is a simple smart contract using an escrow on the blockchain in combination with a time-locked transaction, that solves Bitcoin’s issues of relatively high transaction fees (currently around €0.05), long transaction confirmations times (up to 1h) and bandwidth (only around 3–5 transactions/second are possible).
Around this core protocol we’ve built a payment system with dozens of microservices tucked away in Docker containers and an easy-to-use user interface that requires no onboarding for the end user at all. We are generating a Bitcoin private key on the fly, this was inspired by RushWallet, and use it to sign payment transactions and to identify the user.
Here’s the thing, using Bitcoin’s built-in public key infrastructure in the browser, there is no need for username and password any more. Simply sync your private key around and that’s it. Welcome to the login-less web!
The private key that is generated in the browser is saved in the user’s LocalStorage. This means, we never have access to it and the user stays in full control of their funds. Welcome to web apps with decentralised data storage!
Oh, on the interface: Did you notice how payments on the web are never fun, but real painments (ha!) with all the hoops you need to jump through for your favourite dealer to take your money? It almost appears as if that’s done on purpose. We’ve looked at computer games and how they make spending small amounts really smooth, and incorporated the findings into our UX. Welcome to web payments that don’t suck!
The Road Ahead
We are curious about what you will build using our website widget and API. We also want to know what features you would like to see supported in future, so let us know! What’s coming:
- Support for more content types, like images, audio/video and file downloads
- API for account management for merchants
- Other payment options, for example credit cards
- Reversed payments, from website to end user
- Low level API for payments, so you can build your own UX
Now, have fun playing around and ask us if you have questions. Slack channel on its way, no worries. :)
We are looking forward to see what you create using our API!
Meinhard Benn, Chief Satoshi Counter @ SatoshiPay