RTA Alpha
We are excited to announce that RTA transaction now works end to end for the entire sale workflow – it is stable, and takes just a couple of seconds to get approval on both wallet and point of sale as expected. There is still some work to be done before we move to beta release, and there are many ways to do even more improvements. But here is the most important thing: the first instant payment on a private CryptoNote blockchain is now a reality!The RTA alpha release contains a full set of components necessary to conduct an end-to-end point of sale transaction in real time:
- completely redesigned full supernode, i.e. the supernode that can participate in authorization sample and approve a GRAFT transaction in real time;
- completely redesigned wallet and point-of-sale proxy supernodes, i.e. the supernodes that provides an “entry point” to the RTA network and participate in RTA transactions;
- mobile and desktop wallet and point of sale apps for iOS and Mac OS X redesigned for RTA.
In addition, there is a special testing environment created for RTA alpha testing – alphanet – a dedicated testnet which contains several seed nodes, a miner, proxy supernode cluster with load balancer, and blockchain explorer.
We managed to assemble a very efficient and quite large team of alpha testers – 50+ active members who are able to run both RTA supernode and iOS/Mac clients (wallet, POS). In addition, we have selected an extra “reserve” group of volunteers (also 50+) that will be able to join the testing once it’s extended to the next phases – additional clients for Android/Windows and then beta release.
People familiar with development release cycle know that alpha releases are usually unstable and may lack some features. RTA alpha was not an exception. Once the RTA functionality was released to the alphanet, we discovered issues that we could not see during regular testing. We are able to simulate the real network very well because the alphanet consists of real participants running on different networks and different hardware or hardware abstractions, rather than artificially cloned nodes and supernodes. We really appreciate the patience and positive attitude of alpha testers team!
So it’s time to learn more about the RTA transaction flow, which you will be able to experience in retail stores soon! It is very simple – a couple of clicks (literally) in the wallet app and a couple of clicks at the point of sale app:
Figure 1: GRAFT RTA Workflow Between Mobile Wallet and Point-of-sale Apps
Payment Gateway for Merchants and Service Providers
As recently described in the Fees and economics update post, one of the important profiles in GRAFT ecosystem is a Merchant Service Provider (MSP). An MSP’s role is to provide and support payment network services to the merchant, ensure the uptime of the network (usually referred to as Service Level agreement or SLA), provide and manage equipment (e.g. payment terminals), provide reporting, etc.
To enable an MSP to do this, another type of server is needed – one that would:
- Manage the terminal’s configuration (including wallet address)
- Handle the MSP specific fee economics for the MSP (an MSP could choose to handle tiers of service differently or charge different fees for different transaction amounts)
- Maintain transaction reporting and analyyics for merchants
In theory, such payment gateway can be designed and implemented by a third party such as traditional payment processor that wants to add cryptocurrency payments to their portfolio of services. However, we decided to create a “reference implementation” to enable faster adoption rate as a part of our go-to-market strategy.
Since GRAFT is a decentralized payment network, the payment gateway is multi-tenant, multi-instance, open source app, and everyone can host their own payment gateway and become a service provider on the network.
Payment Gateway is this “fifth element” that is supposed to manage the GRAFT payment apps on hardware payment terminals and GRAFT ecommerce interfaces, and link them with the GRAFT supernodes. Since it has transaction visibility, it is considered part of merchant’s ‘back office’ applications.
Figure 2: GRAFT Payment Gateway, Service Provider Dashboard
Figure 3: GRAFT Payment Gateway, Merchant Dashboard
* Note: With GRAFT network, the merchant can be their own MSP, but would still require the functions of a Gateway in order to manage the terminals setup, reporting, etc.
