Jan 21

Adding Payment Gateways while maintaining Data Security and Focus

| More

As a startup, we face many of the classic trade-offs between getting things done quickly and getting them done the best way possible. The right answer is usually somewhere in the middle. Since we’re dealing with our customers’ money and business transactions, we err on the side of doing things slowly and methodically, especially on core issues.


Hundreds of people want us to add other payment gateways. This is absolutely true for people outside the USA, because they can’t use our currently-supported gateway, Authorize.net, which means they can’t use Chargify. And that’s a shame!

We’ve been gathering info since November on what gateways people want. In parallel, we’ve been investigating ways to add gateways - quick ways vs best ways.

If you’re a developer, you might ask why we don’t write code for each of the different gateways’ APIs. Especially with things like ActiveMerchant (in Rails), we should be able to add gateways very quickly. Yes, but…


Consumers, merchants, and banks are rightfully concerned about credit card data security. In an effort to protect all parties, the Payment Card Industry (PCI) has established standards for how credit card data should be stored and handled. That’s why you see the term “PCI Compliant” at many steps in the payments processing chain.

Because we handle recurring transactions for our customers, we have to store credit card data somewhere. Storing card data is inherently risky. Anyone storing a lot of credit card data has a big bullseye on their back and that bullseye will only grow larger as they store more data.

Storing data ourselves would require us to maintain a group within Chargify that would be devoted (at least part-time) to credit card data security and all the related tasks, like handling a breach or a suspected breach. While I’d like to claim that we can handle that requirement, we’re a small company and we have to choose where to put resources. Other companies have this covered and do a better job than we could do, so paying someone else is a better option that ultimately results in better security for Chargify customers.

Some payment gateways take on the secure storage role: they offer secure data storage as an add-on. Authorize.net is one of them. For $20/mo per merchant, it’s a steal! But some gateways don’t offer this, so that presents us with a problem: We’d like to support those gateways, but we’re not willing to sacrifice credit card data security.


We’ve partnered with a financial institution that securely stores credit card data and connects to payment gateways worldwide. This gives us the best of both worlds: data security and gateway flexibility for our customers.

This path will restrict us a little bit: gateways that don’t have their own storage and that are not supported by our partner will not be available through Chargify.

But our gateway selection is about to get a lot bigger!

I really like this solution because it gives all these benefits:

  • More gateways
  • Better data security than we could provide
  • Allows us to maintain business focus
Cool. When can we expect these gateways to be up?
By patcito on January 22, 2010 at 05:31 PM
Patcito, new gateways will start coming online in the next 2 weeks.
By Lance Walley on January 22, 2010 at 06:07 PM
Chargify seems to say that its customers are PCI compliant ("Achieve PCI compliance instantly" on the home page).

However, Chargify's API seems to accept a credit card number (for example, the Ruby method Chargify::Subscription.create). PCI DSS says "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted."

How does Chargify avoid requiring its customers to be PCI compliant, since the card number is transmitted from the end user to the Chargify customer, and again from the customer to Chargify on its way to a vault? Am I misinterpreting the service?
By Troy on January 25, 2010 at 08:41 PM
Have you thought about allowing for payment by "convenience store" for end customers in Japan? I just had a discussion about SAAS in Japan and discovered that many Japanese are not comfortable paying by credit card. In fact, many don't have a credit card. Monthly payments for many services are done by taking a bill to a convenience store like Circle K or 7-Eleven and paying by in cash.
By Truman on January 26, 2010 at 04:00 AM

Thank you for the great question about PCI. Our customers still have to complete a PCI form, but the D form which is much shorter and requires that the storage and processing be done by a Level 1 complaint company.

Yes there is some risk in the pass-through of the CC data, but this is temporary, in memory and what PCI cares about is storage and that is handled for our merchants in a number of ways.

We also still recommend our client follow best practices of SSL certs, even in memory encrypting data and such. But again most of these are not specific to PCI compliance.
By David Hauser on January 26, 2010 at 01:58 PM

We don't have any plans to support the convenience store payments you speak of. Maybe someday, but right now, we've got our hands full with credit card payments in most countries.

By Lance Walley on January 26, 2010 at 02:20 PM
Thanks for the reply, Lance. Will you be supporting http://www.epsilon.jp/ in your next release?
By Truman on January 27, 2010 at 01:06 AM

That gateway is not on our list, but you can add it (and anything else you want) at chargify.uservoice.com

We are simply following what our beta customers and people on UserVoice are voting for. You will see some other gateways that we must enable first, but I can say that as we add more of them, the process will get faster.

By Lance Walley on January 27, 2010 at 01:46 AM
Thanks David, good feedback. "Achieve PCI compliance instantly" might not be the best way to put it.

Can I ask how Chargify established that PCI isn't concerned (or as concerned) with content that's decrypted on a customer server, kept in memory, and re-transmitted to a provider/vault?

That's the biggest exposure (PCI and actual security) of most pass-through vaulting solutions. Anyone with root on a customer Web server can fairly easily log the decrypted data (among other risks). Others in the industry seem to be concerned enough to try to work around it with hosted order pages/callbacks and the like.

We looked through PCI and alternatives when deciding on a CC solution, and that was the only one that truly seemed compliant - but only because of the in-memory "transmit" wording. If you have other info, it would be welcome.
By Troy on February 2, 2010 at 11:35 AM
Sorry, that should say "We looked through PCI DSS and alternatives to needing to be compliant."
By Troy on February 2, 2010 at 11:36 AM
You are correct there are still local concerns and you must complete the PCI section D form as well as insure you are doing things locally that are correct. Other providers force you into the hosted and widget based setups (both of which we will support) so there is no local concern. However the best solution is you can control everything you want and not need to store anything.
By David Hauser on February 2, 2010 at 11:43 AM
I second the request for Japanese convenience store payments. This is something we *really* want to do. Barring that, other Japanese-friendly payment methods would be much appreciated. they don't like to use credit cards much. One possibility might be keitai (cell phone) payments OR the ability to generate a CSV list of clients to send physical bills to via mail (if that option is selected when a customer is created in chargify).
By Aaron on February 2, 2010 at 03:45 PM
Does this mean that, as a Chargify customer, we will no longer need to purchase the Authorize.net $20/month add-on?
By Logan Leger on February 6, 2010 at 06:18 PM

This is an interesting question and we have not answered it, yet.

In general, I think you should plan to pay the $20/mo fee to Auth.net. We will use gateway's storage when they have it, and this way it stays clean - it's your CIM, your data.

We *could* use our other storage facility discussed here instead, even with gateways that have their own storage offering, but we will probably charge for storage. This is being discussed internally. We are not getting this storage facility for free, so we have to cover our costs.

By Lance Walley on February 6, 2010 at 08:16 PM
Commenting is not available in this weblog entry.