Posts

EMV: A Multitude of Payment Solutions

Clearent Payments API

What is EMV?  EMV, by definition, “is a global standard for credit and debit payment cards based on chip card technology taking its name from the card brands Europay, MasterCard, and Visa – the original card brands that developed it.” That definition doesn’t tell us much. Most of us understand EMV to mean chip cards that can be inserted into a slot in the payment terminal. Chip cards allow additional verification to prevent fraud in card-present transactions. They are much harder to copy than the traditional magstripe.  They also have additional verification built into each transaction so that each use can’t be reused, like magstripes can be.

EMV has disrupted the industry because as of October 2016 the Card Brands (MasterCard, Visa, Discover and Amex) have required their merchants to either accept EMV chip cards, or be responsible for additional fraud liability. This has been referred to as the liability shift. This liability shift has rattled the payments industry. It’s the first time in years that U.S. merchants will be forced to upgrade their point-of-sale (POS) equipment and terminals. Vendors of terminals are scrambling to support the technology and grab more market share; merchants that are forced to buy new equipment start looking at new vendors. Read more

How Our Hosted Payments Page Is Different

Hosted Payment Page 1

Generally, a hosted payments page is a web page your payments provider hosts for you. They aren’t hosting your payments page but rather a generic payments page that your website will use for the payments processing of your eCommerce store, shopping cart, or checkout page. In this case, your customers will come to your website, add products to their shopping cart, pay for their goods and get a confirmation of the completed sale and pending shipment.

The image below shows the typical flow when using a hosted payments page.

Hosted Payments Page Flow

There are many benefits to using a hosted payments page:

  • Reduced PCI scope
    • Because you are not sending financial data to your server your PCI scope is greatly reduced.
  • Ease of implementation
    • Hosted payments pages generally offer much less coding and development time to start accepting payments. This allows you to start accepting payments much faster.
  • Reduced development costs
    • Because development and implementation time is reduced, so is the cost associated with developing a payments solution.

But not all hosted payments pages are created equal. There are also some downsides with using typical hosted payments solutions:

Read more

Why We Use TDD

Love Test Drive Development

Ever since I started working as a developer for Clearent, I’ve been an adamant supporter of Test Driven Development (TDD).  I adopted this development practice a very long time ago and have seen its benefits over and over again.

What is TDD?

Test Driven Development is a coding practice where a developer writes a failing unit test before writing the production code to make the test pass.  Ideally, the unit test is built up slowly, adding a failing test condition that drives the next incremental feature in the code being created.  (We achieve this incremental build-up by practicing a coding pattern called red-green-refactor.)  The design of the code is “discovered” as the test is built-out, and the end product is a well-designed piece of functioning code.  A by-product of this practice is a unit test that can be repeatedly run to ensure future changes don’t break the existing code base.
Read more

Switching to Distributed Version Control

Distributed Version Control

One of the best parts of being a developer at Clearent is being part of a culture of constant improvement and growth. This culture allows us to consistently improve our payments platform and the products we as developers create for other developers to accept payments. We are not a company that refuses to change simply because “that’s the way we’ve always done it”. Every day is an opportunity to try something new, whether it’s a new framework, a new platform, or a new toolkit. All of this, in the name of creating the best possible payments platform.

A couple years ago, we decided to make the transition from a centralized version control system (subversion) to a distributed version control system (git).  And in that transition was a real opportunity to change the way we use source control.

We started with three assumptions:

  1. Branches are Cheap
  2. Merges are Easy
  3. Conflicts are Rare

If you have only used centralized version control systems (VCS), those first two assumptions sound crazy.  Most of the popular centralized VCSs are either incredibly slow to branch or make it very difficult to manage to multiple branches. We had actually built our own internal tool to help us manage merging our long-lived development branch into our testing and release branches. Version control systems are supposed to be a tool that helps developers do their jobs, but for us it almost more of an obstacle.

Read more

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

Succeeding with Failure for Developers

Clearent Developers Failure to Succeed

Developers hope (and pray) that when facing system application failure it does so in a predictable and recognizable way.  Nobody wants to get the 3 a.m. phone call from a sysadmin saying that a core process failed and reported an “unknown error.”  As Clearent has grown we have learned a few things about failure.  We’ve also had to rethink what failure means and how we adapt to the unexpected.  We are continually learning, so I can’t provide a definitive guide on how to write fault-tolerant systems but here are a few things we’ve learned along the way.

Logging

Have a top-level exception handler that logs any error that causes your application to fail.  Hopefully it is never exercised but nobody wants an application that fails and doesn’t say why.  This can get tricky as processes spawn threads, so be aware that it may not always be near the entry point of your application.

Take advantage of logging levels to throttle the amount of data you emit.  Most logging frameworks have the ability to write out messages at levels such as Debug, Info, Warn, Error, or Fatal.  When the going gets tough in production your operations staff can make the logging more verbose to gain insights into what the application is doing.  When everything is operating normally it can be turned back down again without requiring development time to add and remove logging.
Read more

Working Toward Continuous Delivery

continuous delivery

One of the biggest difficulties in software development is deployment.  Figuring out how to package an application, transfer it around, install it, etc. has been a challenge from the dawn of programming.  Continuous delivery is a term used to describe an environment where software flows from a developer into production, through all of the necessary gates, with minimal manual work.  Clearent has always worked to simplify the software deployment process so that we can deliver new features to our customers quickly and efficiently with minimal disruption.  As the underlying technology stack evolves, we are able to move toward a true automated continuous delivery system.

 

Software is typically difficult to release.  The process flow is generally:

  1. A developer creates or makes changes to a piece of software and tests it on a local system.
  2. The software is moved to an integration system to ensure it works with the rest of the software available.
  3. The software is moved into an environment where quality assurance testing can be performed.
  4. The tested software is moved into the production environment.

Read more