Integrating Payments into a Spring Boot Service

RESTful Interface Flow

This is a quick tutorial showing how easy it is to integrate with Clearent’s secure payments gateway. Clearent has designed a language agnostic RESTful online payments gateway, meaning developers of almost any language should be able to start processing with Clearent.

Today we’ll be using Spring Boot and a handful of other libraries to get a payments service up and running fast. Spring Boot provides an opinionated implementation of the Spring framework in an embedded JAR file. We’ve been using it internally here at Clearent for over a year now, and has reduced our development time and has provided quick integration with thousands of popular libraries and tools. We’re going to assume some basic familiarity with Spring Boot, but if you’d like an introduction, Spring’s Tutorial on Building REST Services demonstrates all of the topics covered in this post.

Read more

Distributed Systems for Clearent Payments

Distributed systems is an area of computing that attempts to address the problems some companies have with scaling computer resources once they grow beyond what one machine can handle.  Issues of scale can appear when the number of users, amount of data, or computation requirements grows to a level in which one machine, however large, is incapable of meeting service demands.  For some companies, the amount of data that is required to be online and accessible for reporting or research is so massive that a single database or filesystem cannot store it.  Other companies that handle requests on-demand from users via an API or hosted service find that the number of requests made within a period of time has grown to a point where the system cannot react to every request in a timely fashion.   Computation in some industries can be so large or intense that if one machine is asked to perform it would take so long that the results of the computation are irrelevant by the time it is complete.


At Clearent we use techniques from distributed systems to help level out the time it takes to process batch transactions as our merchant base grows.  Our backend system receives transactions numerous times each day in large data dumps.  Our desire to help merchants get their funds the next day and strict bank funding windows puts pressure on our system to qualify, bill, and settle all transactions within limited timeframes despite the fact that our transaction volume continually increases.  We therefore parallelize the processing of transactions across a network of machines, configured to coordinate and ensure exactly-once transaction processing.  In the event that our system cannot meet the timeliness demands of our partners we can add new processing nodes to bring the completion time back down to acceptable levels.

Read more

Understanding DNX

Getting a handle on the new .NET Execution Environment (DNX) is difficult. I’ve been following the project for a while, and still get twisted around trying to explain it to other developers. I believe the following analogy and diagram help to understand the environment.

Keep in mind, this is a tenuous comparison meant to help people understand the environment. It is not a comparison of the technologies in question.

I often compare DNX and its ecosystem to the MEAN development stack (MongoDB, ExpressJS, AngularJS, and NodeJS). This development stack consists of a runtime environment (NodeJS) that hosts a framework for creating server-side applications (ExpressJS). These server-side applications can be accessed using client-side frameworks such as AngularJS. The entire stack can be backed with MongoDB for permanent storage.

The DNX environment is similar, but much richer. DNX is the runtime environment, much like NodeJS is for the MEAN stack. MVC can be used to create an API (formerly WebAPI*) that runs on the server in DNX, much like ExpressJS is used in the MEAN stack. The client-side component can still be AngularJS that calls the API. This is where the comparison ends.

Read more

Why Clearent Developers Went With Angularjs

It’s 2:00 am and the dog woke me up about a 1/2 hour ago to go to the bathroom. How is it that I can go from being dead asleep to wide awake because of a simple walk downstairs. So while the dog is already back in bed passed out, I’m left to my thoughts. Unsurprisingly, I find myself thinking about our new Virtual Terminal product.

I’m not sure why it popped into my head at this hour, but it was an interesting project for us. We wanted to build a mobile first client that used our public API’s to run transactions, view transaction history, batch history, and more.  Surely if we expected our clients to use our API’s to write rich POS and payment apps, we should be able to write one using the public API’s too, no cheating. If we need additional functionality we would make that public for our client as well.

Naturally as a band of self-proclaimed back-end developers we wanted to avoid JavaScript as much as possible.  I mean seriously dealing with the browser compatibility issues and the quirkiness of JavaScript’s undefined errors did not sound appealing at all to myself or the members of my team.  Having worked at various large corporations throughout my career, I had successfully avoided any difficult JavaScript solutions by passing off that front-end headache to front-end developers, and I was more than happy to do so. I wanted to focus on security, testing, and other concepts that interested me.

Read more

Reflections on Strange Loop and Clearent

Strange Loop Conference

Reflections on Strange Loop 2015:  3 Topics relevant to Clearent’s Payment Processing systems.


2015 was my first Strange Loop conference.  Many interesting presentations were given on topics ranging from tech activism, to functional programming – and everything in between!  However, three topics were particularly relevant to our present work at Clearent: microservice architecture, distributed systems, and container based virtualization.

Many of us have experienced the challenges of developing or maintaining large, tightly coupled, monolithic applications.  As an alternative to a monolithic approach, Clearent relies on a microservice architecture for much of its payment processing infrastructure.  Our Gateway, Vault, and Virtual Terminal are all microservices – running independently of each other. Martin Fowler’s article ( nicely describes the microservice architecture and some of the pros and cons when comparing with alternative approaches.

Read more

Clearent’s Payments API Used At GlobalHack V

“This is probably the most beautiful day of the year and we are inside coding.” Well, I suppose we could have brought our laptops outside.

Clearent is certainly no stranger to hack-a-thons and continues to look for ways to get involved in civic-minded technology projects, including GlobalHack.

At GlobalHackV, teams were tasked with choosing from different pre-defined use cases and were challenged to “build a technical solution that will contribute to a more transparent, accountable, citizen-focused justice system.

Read more

Introducing Clearent to Developers

Clearent Developer Center

Developers meet Clearent. Clearent meet developers.

So this is it. The launch of our developer blog. The goal of which is to bring information and clarity to the world of digital payments, and to the developers who make it all happen.

For those of you not from the world of payments, this space may seem complicated, and justifiably so. So what exactly is “payments?” Simply put, it is the accepting, processing, and transferring of money securely from a consumer to a merchant.

There are many players in this space: issuing banks, acquiring banks, merchants, customers, gateways, processors, aggregators, card associations and ISOs (independent sales organizations), just to name a few. To complicate things even more, many of the players can be combinations of one or several of these pieces. For example, issuing banks can also be acquiring banks, gateways can also be processors, or you can have a gateway, processor, and acquirer – all in one (which is what Clearent is), and so on and so on. For the sake of time and not melting your brain into mush, I won’t go into those above mentioned titles and their definitions until a later blog post.

Read more