NXT solution to payment terminal

This paper outlines the software and hardware of a NXT Point of Sale device, outlining the cost of a single Point of Sale Unit and the Use Case. Preliminary elements are presented, and the customer card and Shop device are detailed.  The process of Paying, methods of security, and future use cases are covered.

In the future, any type of business from your local corner store to a mega-retailer will most likely have a crypto-currency payment terminal. A solution’s framework already exists in the Bitcoin network; it mimics the existing payment terminal network. However, despite the reduced  transaction fee, this current solution does not bring added value to the customer, the shop, or to the network itself. Thanks to its portability, and leveraging its protocol design, NXT offers an elegant answer to the payment terminal case.

From a software perspective, all of what a payment terminal requires exists today, though the NRS client is still a work in progress in the rather young NXT world. A broad deployment of a physical device would require a very stable client and the ability to remotely and massively, deploy any new version.

From a hardware perspective, Raspberry’s computers on which the NXT client can run effectively have all the required hardware, OS and drivers.
Building a connected payment terminal is technically feasible and possible by most of the technical people that are part of the NXT community. Software must be developed to manage the terminal; but some libraries already exist, and most building blocks are in place and working. The two biggest challenges are security and physical deployment. While physical deployment is simply a matter of proper organization, security features are a critical element that must be well thought through to allow a balance between user experience and transaction security.


Raspbian and the NRS client run very well together on the Raspberry Pi platform. The CPU usage remains below 20%, even less than ~10% most of the time (while it occasionally peaks higher and may occasionally spike to full load). The memory usage is around 100MB. All parameters
prove very reasonable performance. The software installed on the Raspberry Pi can easily be managed using remote desktop, or via scripts, allowing for large deployment.

A very complete setup guide to enable NXT client on the Raspberry Pi with detailed steps and all the links required is maintained by the NXT community. While running the NXT client is an easy setup, there would be additional deployment required to integrate a card reader and to make sure a potential customer is able to pay. However, this is currently not out of reach, with card readers having drivers largely available for Linux.


Any Raspberry Pi will do. For this specific paper lets considered the Type B with 8GB SD card features more than enough performance for our requirements. Optionally, a WIFI module such as the Edimax Wireless Nano USB Adapter can ensure high network connectivity data rates of up to 150Mbps. It would even be convenient to have a WiFi feature to allow payment a distance from the cashier desk, like in restaurants where the waiter could bring you the module.

We will need to read and write to/from smartcards to store both the wallet ID and the passphrase. These cards will then be protected by a pin code. Read/Write operations can use any ACR38 USB 2.0 Smart Card reader/writer. They are sold for around 30 euros. We could add a picture of the person who signed the payment as a security measure, similar to what is done for parcels delivery. It would only require the addition of a tiny camera on the Pi and will increase the device cost by only a fraction. Its description/scope of use is beyond the limits of this paper, but it does remain a possibility.

We should also add some casing for the product to look aesthetically pleasing, and some cabling as well. I excluded all this from this paper, as this is a roof of concept, but this would be required by any commercial product. Finally, we need the smart cards themselves. They are sold in bulk, and are inexpensive and easy to find.

This is the overall picture; what we need to buy in order to build our Point of Sales module comes to the table below. Prices are retail prices observed on Internet, considering only 1 item bought and EU VAT. It doesn’t include the delivery costs.

Cost of a single Point of Sale device broken down by Component Price

Raspberry Pi Type B with 8GB SD card € 40,00
ACR38 USB 2.0 Smart Card reader/writer € 30,00
Optional Edimax EW-7811UN : WiFi connector € 13,40
Smart cards € 01,00
Total Hardware cost € 84,40

Use case
Preliminary elements
The customer and their card

The customer is assumed to have a wallet ID, created it for the purpose of paying at shop locations. The wallet is loaded with a limited amount of NXT. The card will be loaded with both the wallet ID (public information) and secret key (encrypted). The card will be secured and will use a 4-8 digits pin code. Loading the card will require software that doesn’t yet exist. When designed, it could be integrated into an official wallet software package.

The Shop and its device

The merchant will buy and setup a Point of Sales module and simply plug it in and enable Internet access. A “to-be-created” setup would help in doing so. The merchant will create a NXT wallet and defines an Alias for it for it to allow easy customer future follow-up. It is likely the merchant will want FIAT to be sent to it’s bank account directly, luckily this is possible with the Automatic Transaction system, part of NXT key features, and currently in testing stage.

For the merchant to accept a payment, it will access a Point of Sales website, which will manage the communication between his Point of Sales module and his shop and will make the link between everything: his module, his wallet id, and his exchange account. The merchant and its device

When the user reaches the shop, the main flow of the use case is the following:

1. The Point of Sales module, being idle, loaded the shop account id, and runs into “Node” mode, helping the network secure itself.

2. The cashier connect to a specific website, introduce the sale’s detail and, in return, the website sends the payment instruction to the Point of Sales module. This module close the shop’s account and wait for the customer to present his card.

3. The customer present his card, the module read from the card, decrypt the wallet id, identify the account, verify it has enough cash from the block chain. Present the result to the cashier (who is still connected to the website).

4. In order to decrypt the passphrase, the module request the pin code from the customer, who type it in. The module reads again from the card, decrypts the secret passphrase and executes the payment. Finally, it provides confirmation to the cashier that payment transaction was initiated.

5. Payment is done!

6. The shop might want to wait for the transaction to be confirmed. However, it is likely that for small amount of money, Instant Transactions, when it will be made available, would be sufficient. Instant Transactions is a mechanism for sending transactions through the network with “guaranteed” confirmations, making transactions valid almost instantaneously. It is not today implemented, but is on the todo-list.

7. Now that no sales is being made, the Point of Sales module close the customer account, delete all information it had and enters back into “Node” mode.


Security is of utmost importance in this project. This area is where the most work is still required. Three aspects are particularly interesting: the payment transaction itself, the module (and website) resilience and, of course, the Point of Sales module availability.

From the “payment transaction” angle, at least two features would protect the user:

a) A two-step approval: there would be a two-step approval of any transaction. Step 1, confirm the wallet id and amount, and step 2, confirm transaction generation. Of course the network will still manage the transaction itself.

b) The data on the card would be encrypted, and only encrypted data would reach the terminal. This terminal would then decrypt it, and process accordingly. The payment module itself requires a high level of security, to ensure no one can break into it.

c) Visual identification via the camera module is also an option, requiring for example the user to show a specific QR code he has created, adding a third layer of security. There is a risk for the module itself. Its address will be publicly and widely available on the Internet, since it would be a NXT hallmarked node. An attacker could try to hack it to retrieve the wallet id and secret phrase of the users. The risk of an attacker to succeed is potentially higher than with proprietary technologies, as the technologies used are more exposed and well known than with proprietary technologies. A DDoS type of attack on the module itself is also possible, impacting the shop directly. This second risk is much larger and should be addressed.

Finally, there is a risk on the website used by the merchants. It is a single point of connection (and failure) for all the merchants, or at least a large fraction of them, in case there would be a geographic distribution of the merchant connections. As an example, it could either suffer Man in
the Middle type of attacks, or DDoS attacks.

Future use cases

Having access to the block chain at Point of Sales would allow for many possibilities. It would for example give an immediate view to the seller when, if ever, this person last had a transaction at that merchant, and allows the sales guy to act accordingly. It also would allow him to know if this person went to a competitor, and potentially proposes some desired action. It would allow the merchant to know which markets its customers usually shop in, and at what time this user usually shops. There could be a link between the online experience and the physical experience
at a certain retailer, provided the user and the retailer use the same account IDs, the retailer will know it easily and would then recognize his customer. All these elements are publicly known on the block chain, and could be easily retrieved.

Raspberry & NXT in NXT wiki : http://wiki.nxtcrypto.org/wiki/How-To:InstallNRSRaspberryPi

NXT Payment Terminal Parts
Core Raspberry component : http://raspberrypi.rsdelivers.com/product/rs/pi-bsd/raspberry-pi-type-b-with-8gb-sd-card/7858654.aspx

Optional WiFi module : http://raspberrypi.rsdelivers.com/product/edimax/ew-7811un/edimax-wireless-nano-usb-adapter/7603621.aspx

Optional camera : http://raspberrypi.rsdelivers.com/product/raspberry-pi/camera-module/raspberry-pi-hd-video-camera-module/7757731.aspx

Author: frmelin     Proofread: opticalcarrier

About Brian Snyder (15 Articles)
Brian is an entrepreneur and a long term diversified investor, always holding assets with low to zero counter-party risk. He holds a B.A. in Business Administration with a Major in Management from Washington State University. Brian has 15 years of experience in information technology, always exploring the leading edges of technology. His current areas of focus are decentralized peer to peer networks, applications and currencies built on top of the Nxt green network.

Leave a comment