How to Deploy a PCI-compatible Application on Heroku

Last updated 09 September 2015

This document explains the options available for deploying a PCI-compliant application on Heroku. Because Heroku itself is not PCI-certified, applications should be designed to fully-outsource payment processing. There are a few technical considerations to be aware of that affect compliance, however.

What is driving this?

Previously, merchants using 3rd-party payment providers (3PPs) could self-assess their environment using the SAQ-A form (regardless of whether the processing was done on the client-side or server-side.) The SAQ-A is a short, easy document — about a dozen questions, easily completed within a day.

With PCI 3.0, there’s a new form, SAQ A-EP, which is for e-commerce merchants who outsource their transaction-processing functions to PCI DSS certified third-party service providers (called partially-outsourced, or server-side implementations.) SAQ A-EP applies when the merchant website controls how the cardholder data is redirected to the third-party service provider.

Customers who don’t allow cardholder data to hit Heroku — for example, using redirect-based flow (PayPal, Amazon Payments) or an JavaScript/iframe solution (Stripe, Braintree) — are still considered fully-outsourced and can continue to use the SAQ-A.

Guidance for customers

In order to meet PCI requirements on Heroku, the payment processing should be fully outsourced (i.e. client-side implementation) by a 3rd party.

Here are some options for implementing or switching to a compliant solution.

Stripe

Stripe addresses the new requirements and explains how to avoid the SAQ A-EP here.

Here is a detailed tutorial on how to convert POST method (non-compliant) to .js (compliant).

Another simpler option, which doesn’t require coding, is to use Checkout.

A third option is to employ one of Stripe’s PCI-validated vendors.

Spreedly

Spreedly employs an iframe solution.

ChargeBee

This tutorial explains how to deploy an in-app checkout page using Stripe.js to create subscriptions in ChargeBee and store and process payments on Stripe. Stripe.js makes it easy to use any form page as a checkout page, and also reduces your PCI DSS scope. It does this by taking care of all the sensitive card information for you.

Background: requirements for small businesses

What does a small-to-medium sized business (Level 4 merchant, < 20,000 transactions/year) have to do in order to satisfy the PCI DSS v3.0 requirements?

To satisfy the requirements of PCI, a merchant must determine which Self Assessment Questionnaire (SAQ) should be used to validate compliance. There are two types:

SAQ-A: This is for merchants with fully-hosted payment processing; all card functions are outsourced. stripe.js, braintree.js, stripe checkout, are all designed so that payment data doesn’t hit the backend, which means they’re covered by the much simpler SAQ-A.

SAQ A-EP: This is a new SAQ to address requirements applicable to e-commerce merchants with a websites that do not themselves receive cardholder data, but which do affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

The two examples of this are:

• Shopping cart or payment page partially outsourced: during payment, the consumer’s browser is redirected to a payment page that is controlled by a PCI-compliant 3PP, BUT some elements (JavaScript, CSS, etc) are passed from the merchant page to the 3PP page.
• Shopping cart or payment page direct post: during payment, the checkout/payment page directly posts payment information from the merchant site to the 3PP, but the page resides on the merchant site.

Technical background: how Stripe 3rd-party processing works

Stripe’s JavaScript is not executed on any server, only on the client’s browser. The client’s browser sends the card number using an asynchronous call to Stripe’s endpoint over HTTPS, and a random generated token is returned. After that, the form is submitted to the merchant’s web server, but with the token instead of the raw card number. The merchant’s server side then makes a call to Stripe’s API with the token to finalize the payment. As a result, the card number never touches the merchant’s server, and so the merchant’s application and infrastructure is out of scope.