Lead Engineer

Payment applications with Ruby

Thiago Scalone,

CloudWalk is a group of talented people that has been working with technology, IOT, POS, embedded devices for more than a decade. In this article we will describe how we delivered payment solutions to POS terminals efficiently, using mruby.


Payments, POS e IOT

"An embedded system is a computerized system that is purpose-built for its application" - Elecia White, Making Embedded System

Payment market have been using embedded machines created exclusively to perform the capture of financial transaction. This small device concatenates the basic needs of disk, firmware, OS, drivers, input interface, external communication, and of course, the most important security.

The hardware required to guarantee all these needs cannot cost a fortune, and still has to cover the basic SDK for development.
In this way, the best language to fit in this context, thinking in performance and development SDK cost, would be C, but as the C found in those environments, may not often be a C99 implementation, there are some others points that would be distinct than usually POSIX PC, for example:

  • Some of them do not have an OS, just a basic firmware and a set of functions to be used by the developer;
  • Limited set of syscalls, Non-POSIX devices does not support some syscall as pipe;
  • Bad and poorly documented SDK, in some manufacturer the only documentation are the C headers files;
  • Non-ASCII C, it is not every manufacturer that follows a C specification, such as a C99 or C11.

Development Flow

The development flow of an embedded terminal is not as mature, by context, as a backend development, in many cases as tooling lacking for unit tests, CLI/Shell, continuous deploy, high-level debuggers, and so on.

In many cases the development flow consists of:

  • Development in C;
  • Cross Compilation using the manufacturer's tool, which is usually a Windows based application;
  • Signature with binary structure;
  • Manual upload in the machine;
  • Test and validation;
  • Mass storage, which most manufacturers have remote terminal upgrade support, but few have automatic remote actualization, meaning that manual update is required.


  • Specific C development, create mature teams to develop payment solutions for terminal demands a high cost and long learning curves;
  • Predominant Windows, and some cases forced, as development environment;
  • Slow, complex and bureaucratic development flow, not compatible with the demand for new deliveries and solutions;
  • One implementation for each model / terminal manufacturer.

The solution

We had to deliver the state of the art of payments, with a better experience, developed in an elegant, dynamic and efficient way, dealing with a complex ecosystem of POS terminals, without a budget or enough people.
Then we decided to create an ecosystem based in some embedded runtime, with an API focused on the developing of payment applications.

With it in mind we created some goals that would need to cover:

  • Rich and hacker-friendly development environment;
  • The same runtime should be portable enough for all machines on the market;
  • The runtime must be small;
  • The runtime must be open source;
  • Attractive for new hardware manufacturers, being easy to homologate.

Rich and hacker-friendly development environment

A hacker-friendly environment consists of an IDE independent environment where you can choose where and how to develop your applications. Where it can execute commands in any shell (PowerShell, Bash, Zsh and etc), and mainly develop functional and fast applications.

A rich environment is one that gives you the freedom to develop the best way to implement your algorithm, as well as a tool that at all levels of support:

  • Library of unit tests, functional tests and integration;
  • Execution shell of commands that simulate a POS terminal behavior;
  • Small learning curve with scaffold to simple applications;
  • Support for version control like Git and Mercurial;
  • Language with multiple paradigms in favor of quality, freedom of choice and maintainability;
  • Comprehensive SDK, well documented with several examples;

The same runtime should be portable enough for all machines on the market

A portable runtime is a modular software where the developer can choose which resource (printer, modem gprs, modem wifi) implement. A runtime that has the minimum of dependencies with the operating system and standard libraries, which is maximum self-contained possible. An example of this is the SSL / TLS library used by the CloudWalk, ARM mbedtls, that is optimized for embedded and it is fully contained in the runtime, is not a shared library dependency of the environment. In this way, we have removed a possible dependency with OpenSSL or any SSL / TLS library from a possible manufacturer.

The runtime must be small

A good part of the devices available in the market is low cost. An example is the PAX D200 that has 500k of RAM, 8mb of flash and 100mhz;

The runtime needs to be open source

To bring another perspective on the reason for open source I'm going to share a piece of open source text from the google page that covers the subject brilliantly:

Releasing a project as open source allows others to adapt and build on top of your project. When people build on top of your project, they are invested in your success as well as their own. In cohesive communities there are frequently skilled participants who move across company boundaries with a primary affiliation to the project. This set of portable skill sets reinforces the ecosystem growth in addition to helping provide more diverse viewpoints to the project.

Check the full version: https://opensource.google.com/docs/why/

Attractive for new hardware manufacturers, being easy to homologate

Attractive for new manufacturers, so everyone can homologate the new runtime easily, without depending on CloudWalk. By homologating the runtime, the manufacturer has access to an ecosystem of new payment applications and acquirer, ready to use.


In runtime evaluation process many were analyzed Ruby, Java Embedded, JavaScript, Lua and etc. And in the emergence of a new implementation of Ruby, the mruby, our needs were met.

The first Ruby release was made in 1995, a language created by Yukihiro "Matz" Matsumoto. Matz wanted something that was simple enough for beginners, but also powerful enough to suit experienced programmers. And it achieved this by combining elements from several languages, such as Perl, Lisp, Ada, Eiffel and Smalltak.

The current implementation of Ruby (CRuby) was not able to meet us at that moment, although very powerful and easy to understand and extend, we needed something small and more portable, characteristics that we discussed earlier. It was then that in 2012 where Matz created mruby, a lightweight implementation of the Ruby language, in conforming to the Ruby ISO standard. Matz created the new Ruby implementation thinking precisely in the context of IOT and embedded applications.

mruby-cloudwalk-platform and da_funk

Using mruby we have created some projects that are the basis of the CloudWalk ecosystem of developing payment applications for POS terminals.

mruby-cloudwalk-platform is the project responsible for the homologation/support of new devices, using mruby's toolkit this repository provides support for cross-compilation of new platforms, and the minimal and modular API between the device (in C) and the da_funk framework (in Ruby).

da_funk is an embedded system framework optimized for programmer happiness and productivity in a sustainable environment, it encourages, modularity using Adapter Pattern, and a beautiful code using convention on configuration.

Cognize, share, study and contribute

CloudWalk ecosystem of application development, check our product page

Ready to use, here

mruby-cloudwalk-platform repository

da_funk repository

mruby repository


Ruby Language

Ruby from other languages

MRuby page


Video, Matz about MRuby

About the author

Scalone is responsible for transaction capture in CloudWalk. He has 12 years of career 10 of them with Ruby and 7 of them with C on payments. Ruby lover and active participant of Ruby language community.