Posts

OWASP Security Vulnerability #9 – Components with Vulnerabilities

Developer Cyber Security PCI

This post is a continuation from my first Developer Blog post “PCI Check Up” – outlining the OWASP Top 10 web security vulnerabilities.  We keep these security vulnerabilities in mind as we build out our own payments platform and provide integration points to our partner developers.  In this post, I will review the number 9 OWASP web security vulnerability.

The number 9 vulnerability is Using Components with Known Vulnerabilities.  Most modern web applications take advantage of third-party libraries or frameworks that facilitate application development.  If those third-party components have vulnerabilities in them, then by extension any application that uses those components have security vulnerabilities.  It seems fairly obvious, but many developers simply lose site of this concern.

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

10 Common Mistakes in Web Development

 Web-Development

10 Common Mistakes in Web Development

Carl Armbruster

Senior Software Engineer, Clearent LLC.

I began my web development career in 2001. Back then FrontPage was still a thing (although no one actually liked it), websites used “mystery-meat” flash navigation and someone everyone though a splash screen for your website was a good idea. A lot has changed but I still see too many common mistakes web developers make. Here are 10 of the most common mistakes I have noticed when browsing the web and in my own work experience.

Trying to make your company website the next social media sensation

I get it . . . we all have big egos. You are really proud of your bookstore (café, clothing store, candle shop, etc.) – and you should be! It takes a lot of effort to run your business. But your customers generally come to your website for information, not to hang out. You are not Facebook (unless you work on Facebook’s website in which case you are Facebook). Stop it with the animations. Quit with the music automatically playing in the background. Stop making me register just to browse your website.

Not eating your own dog-food

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

Development Goodness

Developer Pie

Aptitude + Attitude + TDD + Pairs = Software Development Goodness

Hi my name is Mark Sundt and I’m the Chief Technology Officer of the credit card processor Clearent. I’ve been in this role for the last two and half years and have been lucky enough to be in an industry that is undergoing incredible changes and with it new and exciting opportunities.

During my tenure here at Clearent, I’ve had a fairly simple job philosophy / mantra. I really believe my job boils down to focusing on three general things; People, Process and Technology. I’ll talk about technology and process in a future blog post. Right now I would like to briefly discuss what I think makes Clearent one of the greatest places I’ve ever had the opportunity to work, and that’s the people I am fortune enough to work with every day!

Read more