Original post:
https://medium.com/deviota/carriota-direct-debits-on-the-tangle-ef32ea42948f
CarrIOTA: direct debits on the tangle
As promised in the CarrIOTA announcement a week ago, this post will briefly explain how we are implementing the direct debits on CarrIOTA.
What are direct debits?
In a nutshell, direct debits is a financial agreement where one entity can withdraw funds from another entity’s account. In banking, it is a popular way for automated payments where a business withdraws funds for the service provided to you. You don’t have to do anything, apart of granting the right to withdraw your funds.
The automated payments is an important part of any alternative payment system that want’s to compete with the traditional banking. Even PayPal has it’s own flavour of direct debits (“preapproved” or “automatic” payment, as they call them). Managing all your financial flows without some kind of automation would be a huge burden and a barrier for mass adoption.
That’s why we decided that a modern financial manager should include some sort of automation. And here’s how it works on CarrIOTA:
Direct debits on CarrIOTA
Setting up the direct debits on CarrIOTA is a simple 3-step process:
You create an entity on your CarrIOTA representing the business that you want to set up the automated payments for.
You grant withdrawal rights with validity date and maximal withdrawal limits.
CarrIOTA generates a private-public keypair and a new address on the specified seed/wallet. The address and the public key is coded into one string that you have to provide to the business entity.
The private key is associated with the newly created right and stored within CarrIOTA.
Next step will be to simplify the process even further where the permission can be granted in just one step for the user (similar to Facebook app permission granting). More on that soon.
How does the business request a payment?
Using the generated public key the business can publish an encoded message to the given address. Only the holder of the private key (that is, your CarrIOTA) can read and react to that message.
CarrIOTA has a cron job running periodically that checks all the “direct debit” addresses for new messages. Once a new message (that is, a 0-value-transaction with the encrypted payload) is received on an address, your CarrIOTA does the following:
Check if the message is encrypted with the correct public key (decodable with the stored private key associated with the given address). This makes sure that the message came from the authorised party.
Check if the requested amount is allowed: whether the amount is within the specified right limits and whether the right is still active.
Make a new transaction with the requested amount to the given address.
For additional security reasons, there will be an option to set a fixed destination address for all business entity payments. So that if a malicious third party got hold of the public key + “direct debit” address and requested a payment, the payment would always go to the fixed destination address, making this kind of attack futile.
We will provide business libraries (JS and Python) for the businesses to facilitate CarrIOTA direct debit integrations. This opens up incredible possibilities for one-click purchases and donations straight from your browser (more on this in the next article).
Why not a regular API over HTTP?
There are several reasons we are using IOTA’s tangle for API communications instead of the regular API requests over HTTP:
The IP of your CarrIOTA might change without affecting the direct debits. This way you do not have to update the IP address in each “connected” business entity. As long as the address stays the same, you do not have to worry about dynamic IPs.
Security. Your CarrIOTA could work behind a firewall or on a VPN without outside access, apart of the connected tangle nodes, and still receive the API requests. The less people know the URL/IP of your CarrIOTA, the better. You are much safer, if an attacker doesn’t know where to attack.
What about MAM?
The MAM was released after we formalised our direct debit API. We still think, that it would be an overkill for the given use case.
More info coming soon. Stay tuned!
Thanks for reading!
Roman Semko
http://www.carriota.com