Spreedly Blog

Mobile, Marketplaces and Platforms

The transition from web to mobile includes a consumer behavioral change of using mobile apps instead of a web browser. This transition is changing the way commerce happens online, since consumers are less likely to enter their CC data into a mobile app due to the form factor. Further, redirecting users to a third party site for a transaction was workable in a web browser but can be a disastrous user experience in a mobile/app world, with many third parties having poor flows on the web that are horrific on mobile. A poor purchase flow hurts all 3 parties involved – consumer, merchant, and payment provider – as it results in much lower conversion rates.

One point of proof of this change was the announcement this week that Google is going to roll out a “Buy Now” button.  Just a few years ago consumers ready to buy a product would pull up a web browser, search on Google, click an ad and go to the website, enter in their CC and all their address information and purchase the product. In a mobile world they now open their Amazon app, search for the product, click buy and get free shipping via Prime. Google sees this as a major threat since it pulls away searchers intent on buying, who in turn are the consumers that advertisers are willing to pay to reach.

This new type of consumer buying behavior creates several risks and opportunities for merchants. The first thing is the “marketplaceization” of online commerce (yes I totally just made that up). For ease and security reasons consumers will only want to work with a finite number of apps on their mobile devices. Those apps will need to include search (choice) and payment (security and ease). The result of these pressures will result in 3 to 4 very large cross vertical marketplaces – Amazon, Alibaba, and Google if they can pull it off – and a host of focused vertical marketplaces: travel, business services, transportation, ticketing, donations, healthcare, etc.

If I’m making an impulse buy to purchase two tickets to the Durham Bulls baseball game tonight I’m going to want to open SeatGeek, search quickly, get a recommendation on the best value seats then click the buy button and be done. There’s a chance I’ll download the Durham Bulls or MLB mobile app, get comfortable with the UI, enter my card data and address and then buy, but the conversion percentage drops dramatically especially in the context of an impulse buy. That’s why these marketplaces can work for all 3 participants. The consumer is happier, the marketplace is driving incremental sales (discovery) and/or higher conversion rates than a stand alone app, and the merchant moves more product.

Spreedly is focused on enabling the payments component for platforms and marketplaces. Discovery and search apps ready to enable commerce need to securely store a card once and then allow the consumer to buy multiple times across all the different merchants on their platform or in their marketplace. That could mean using Stripe Connect or WePay to create a merchant account for sellers (a common approach we see new startups just launching take), but larger merchants tend to already have a merchant account and feel strongly about being the merchant of record and are adamant about not using something new. And there may be a need to transact against existing 3rd party API’s – Expedia, StubHub, Walmart, etc. – to pass in orders, a use case traditional payment providers don’t support. Spreedly is a tool that marketplaces can leverage to support all 3 choices in any combination they need, and improves the experience for all parties involved.

To be sure, web/browser based commerce isn’t going away soon. However as online commerce grows within mobile apps the winners of each vertical will tie together discovery, selection, payment, and customer satisfaction. Merchants may fear the power of their vertical leaders but they may also see reduced development costs and incremental revenue by effectively outsourcing their development and advertising efforts.

Credit Card Portability

It wasn’t too long ago that nearly all online payment gateways refused to return your credit card data when closing your account. It was the ultimate case of lock-in; you can change to a new merchant account and payment gateway but you’ll be asking all of your customers to re-enter their credit card data.

Braintree really deserves the credit as the first payment company to reject this approach. They even helped create the Credit Card Data Portability group. It was probably helped that at the time they were the new payment provider on the block seeing a lot of potential customers locked to their old providers.

At Spreedly, we’ve embraced the concept of card portability from the very beginning. Now we’re taking it a step further. You no longer even have to ask Spreedly to get your data back. Via our API, you can securely move card data from your PCI secure Spreedly environment directly into that of a PCI compliant gateway. The caveat is that the gateway has to support the concept. You can learn more about it here in our docs. 

If your preferred gateway isn’t supported we’ll still do a manual export upon request. However over time we expect to be continuously expanding the list of supported gateways over time. Our goal here is the ultimate flexibility and peace of mind.

Spreedly Releases Universal Apple Pay Support

Spreedly helps minimize PCI compliance scope and reduce development costs for platforms and merchants that work with multiple payment gateways and/or third party order processing API’s. We do that via a universal credit card token that you store once but use anywhere. We want that story to remain the same as we add support for mobile platform payment services like Apple Pay. We now support the ability to use Apple Pay payments across compatible endpoints, without being locked into a single gateway. Here’s how it works:

  1. You provision your Apple Pay certificate from Spreedly instead of any single gateway.
  2. To execute a transaction, send the Apple Pay payment token to Spreedly along with the gateway you wish to execute against.
  3. Spreedly decrypts the payment token using your Apple Pay certificate and passes the decrypted card number and cryptogram to the gateway, which processes the transaction.

Having Spreedly manage the Apple Pay decryption has several benefits including: 1) the flexibility to process against more than one gateway within the same iOS application, 2) the freedom to change gateways without re-provisioning your certificate and having to release an app update, and 3) the ability to execute against non-gateway payments APIs.

The main requirement for Spreedly’s Apple Pay support during this beta period is that the endpoint’s API supports network tokenization (basically, that it accepts a card number and corresponding “cryptogram” which provides additional security and verification to the transaction). The introduction of Apple Pay has many providers adding support for network tokenization so please contact us if your gateway or endpoint is not yet supported by Spreedly.

Crossing $50 million per month

At Spreedly we’re challenging the status quo that a single payment stack is the right way to scale for web and mobile payments. December 2014 was our 22nd month since we (pivoted) launched Spreedly as a service that solves for the development and data ownership/PCI challenges in digital payments and maximizes the ease with where and how you transact with your data.  As the blog post title states our customers processed $50 million in credit card transactions on our platform for the month of December 2014.

Many of our earliest customers took a big gamble on relying on such a small startup to help power their payments. So we want to let you know that we’re making great progress and plan to be here for a long time in the future. And better still if you’re one of those who’s been on the fence come on in the water’s fine.

Using an iFrame Payment Form with Spreedly

PCI-DSS v3.0, which went into effect on January 1st of this year, mandates the use of an iFrame-based payment form for merchants wishing to minimize PCI compliance scope (defined as the ability to self-assess using the SAQ A questionnaire instead of the more onerous SAQ A-EP). We previously wrote about maintaining PCI compliance in light of the new PCI-DSS requirements and invited customers into our iFrame payment form private beta program. Since then we’ve worked with several customers to integrate the payment form into their payment page and are now making the iFrame payment form available to all customers as a public beta.

As a public beta, the iFrame payment form is functionally complete and available to all customers wishing to integrate it in their production systems. Although changes are expected before general availability, the iFrame form is implemented in a way that avoids breaking changes unless an upgrade is explicitly initiated.

We’ve created a sample app showing the iFrame payment form integrated into a typical checkout page, highlighting the ability to maintain a consistent UX even when using content served by Spreedly. As you begin the process of reassessing your PCI compliance in 2015, please review our iFrame payment form documentation and integrate it into your systems to lessen your PCI burden.

PCI-DSS v3.0 for Online Merchants

Nothing strikes fear in the heart of an online merchant quite like PCI-DSS – the set of “technical and operational requirements designed to protect cardholder data” put forth by the credit card networks (Visa, MasterCard, etc…). If you accept credit cards online, even if you’re not storing or processing those cards yourself, you need to be aware of its requirements and prepared to invest some time into compliance.

The recent upgrade of PCI-DSS from v2.0 to v3.0 introduced some important changes, making now a good time to review your steps to compliance as well as highlight what’s changed.

Do I have to get PCI certified?

If you accept credit cards from your customers then, yes[1].

Many gateways and online payment processing solutions will claim their drop-in credit card widgets exclude you from PCI compliance or make you PCI compliant. This is not true. Even if a third party is handling the collection, processing, and storage of protected cardholder data, you must still go through the PCI assessment process. What these type of solutions do, including Spreedly’s, is reduce your compliance burden. You still have to certify, but can often do so with much less effort than if you were processing and storing the card data yourself.

How do I get PCI certified?

PCI certification takes two forms: Self-assessment (i.e. do-it-yourself) or hiring a third party QSA (Qualified Security Assessor). Though there are obvious advantages to self-assessing, including effort and cost, your ability to self-asses is dependent on your annual transaction volume and is reflected in the resulting level of PCI certification (1-4) you attain.

The following table describes the relationship between your transaction volume, required assessment approach, and level of certification:

If you have… then you can… to achieve
less than 20,000 online transactions per year self-assess PCI Level 4 certification
between 20,000 and 1 million online transactions per year self-assess PCI Level 3 certification
between 1 million and 6 million online transactions per year self-assess PCI Level 2 certification
over 6 million online transactions per year hire an independent assessor (QSA) PCI Level 1 certification

Note: While PCI-DSS outlines the requirements to become certified, there are subtle differences across payment networks (the table above was created from the Visa merchant guidelines). It is ultimately up to your merchant/acquiring bank to determine what is required for your compliance. Please be sure to check with them before beginning the compliance process.

How do I self-assess?

If you are processing less than 6 million online transactions per year it’s quite likely you can self-assess. This is a good thing, but you’re not out of the woods yet. Depending on your level of involvement in handling card data, you may still need to complete a lengthy questionnaire and perform an extensive internal review.

Self-assessment for online merchants usually occurs by filling out one of three self-assessment questionnaires (SAQs). Listed in increasing order of scope they are SAQ A, SAQ A-EP and SAQ D. By way of comparison, the SAQ A has fourteen questions listed while the SAQ A-EP has over one hundred across almost thirty pages. Assessing under SAQ A is, for obvious reasons, the goal of most online merchants.

So can you use the SAQ A? It depends on your technology and provider choices, both of which dictate how card data passes from the consumer, through (or around) you, and onto your gateway:

If your systems… then use
do not touch, process or store cardholder data, and do not serve any card collection forms SAQ A
do not touch, process or store cardholder data, but do serve card collection forms SAQ A-EP
do touch, process or store cardholder data SAQ D

SAQ A-EP is a new questionnaire, as of PCI-DSS v3.0, and its distinction from SAQ A is a subtle but important one…

SAQ A vs. SAQ A-EP

Prior to PCI-DSS v3.0, merchants that used Javascript libraries or transparent-redirect forms from PCI DSS compliant third-party service providers were able to self-assess using SAQ A. These two approaches let the merchant host the payment page, with the sensitive card data being passed directly from the user’s browser to the gateway, bypassing the merchant all together.

With Version 3 of PCI, however, merchants can no longer even host the payment page if they wish to qualify for SAQ A. In order to qualify for SAQ A you must use a payment form that is hosted by and submits directly to the compliant third party. In pure browser technology terms this means that you must use an iFrame-delivered payment form or a hosted payment page from your payment processor[2].

Having a payment form that is served by and submitted to a compliant third party reduces the attack vectors by which a malicious party is able to gain access to a user’s entered credit card data. For instance, an attacker that gains access to your merchant systems can no longer compromise your payment page and siphon off card data before submitting it to the intended processor. The card payment form is protected from such intrusions by web browsers’ cross-domain security policies which limit the ability for pages on one domain to access the content of pages on another domain.

While there are always risks of compromise for any approach, PCI-DSS has determined that an iFrame or hosted payment form is less susceptible than an in-merchant form.

Spreedly customers wishing to switch to an iFrame-based payment form can contact us to take part in our iFrame beta program.

Proof of compliance

Once you have self-assessed using the appropriate questionnaire you will need to fill out an attestation of compliance, or AOC, to formally declare your PCI compliance results. If you have gone through a review led by an independent QSA, you will be issued an AOC.

In addition to the AOC, which needs to be reviewed and re-issued on an annual basis, you will need to sign up for a quarterly security scan of your systems from an outside provider. Together with the AOC, the quarterly scan verifies that you are maintaining your PCI compliance. An example of both the AOC and scan can be found on Spreedly’s PCI page.

Summary

PCI is not for the feint of heart, but it can be managed. When evaluating your compliance, keep the following in mind:

  • What level of compliance you need is determined by your merchant bank, informed by the number of annual transactions you are processing.
  • Self-assessing is less costly and time consuming, but is only an option for merchants seeking less than a PCI Level 1 certification.
  • If self-assessing, using a PCI compliant service provider that provides an iFrame or hosted payment page results in the least compliance burden.
  • An AOC, together with a quarterly scan, is your proof of PCI compliance.

Good luck out there!

Spreedly and “Buy Buttons”

For many years sellers on the Internet set up their website, hooked up a payment gateway and started selling, and buyers came from search engines, either via SEO or paid search. With the rise of social sites like Facebook, Twitter, and Pinterest merchants found a new avenue of traffic from social media. All these different channels employed advertising models to generate revenue while the merchant focused on e-commerce/payment/subscription models. Things were simple.

However, the rise of mobile at the expense of web has major impacts for “where” online commerce happens, with many online experiences moving from the web to device-based apps. In addition, Amazon has created a closed loop of mobile app, search, one click buy, deliver that is threatening Google’s dominance of search. This is creating enough of a threat that now Google might build a “buy now” button to try to protect themselves.

New startups, focused on social and search, have embraced optimizing the app experience – indeed some have ignored the need for a traditional website at all – so the rise of the mobile app is impacting the traditional flow of converting advertising to realizable commerce. Today, while end users are still being redirected to merchants to make the final purchase, often these experiences are starting on a mobile app with the end user being redirected to a more traditional web browser session to complete the process. Or perhaps they’re instead moving from an extremely good mobile app experience to a relatively poor one, which can be a jarring experience that impacts conversion rates. Either way, users – particularly social users – hate the disjointed experience and are frustrated by the inconsistent flow, often blaming both the merchant and the social platform. This has created demand for social platforms to optimize the e-commerce experience and ensure the checkout flow is as seamless as possible given they now have skin in the game.

More specific to search (vs. social), the rise of Amazon has become a real threat to Google. Again, this is mostly app vs web, with mobile users opening a well designed Amazon app and searching for a particular product. The ease and simplicity of one click payments and shipping makes for a completely closed loop. The natural response is for Google to be pulled into controlling e-commerce that originates across its search platform, yet it’s unlikely that merchants, even if they’re feeling the pinch from Amazon, are excited about moving more of their relationship to Google. While there will always be tension in this model over “who owns the customer,” the combined Amazon and Google threat creates a very viable opportunity for vertical search and social solutions to thrive. Google and Amazon will inevitably compete on price (the lower the merchant price the better), but optimized vertical search services on the other hand often bring in a different, less price sensitive buyer that merchants find desirable. A good example of this is Wanelo, who leverages it to achieve 10 – 15% in referral fees.

There are several core components to a “Buy Now” button:

  • The end user wants an Amazon or Uber like one click experience. They need their payment method stored securely and easily accessed for repeat purchases. In addition, support for newer payment methods like Apple Pay, Google Wallet and Paypal need to be seamless choices.
  • Ideally the end user stays within the originating mobile app but the commerce still happens with the merchant. By staying within the mobile app conversion can be optimized. By transacting against the merchant’s existing payment infrastructure the money flow is not interrupted. This is key in terms of customer support, refunds and returns etc. This also helps solve the dilemma around customer ownership, since it’s now explicitly shared.
  • Merchants have to allow third parties to freely access and present accurate inventory real-time.

Spreedly helps social and search services securely store and tokenize payment data, and this truly universal token can be used across multiple merchants over time giving complete independence. Then via our wide range of pre-existing integrations to gateways and third party API’s we help ensure the end user can stay in app while the transaction processing still happens via the merchant’s existing processing relationship. What we don’t solve today is supporting the entire product or inventory management component; we at least help by acting as a passthrough, but the development work falls on the social/search platform and merchants to get the integration up and running. That may be why areas like ticketing (SeatGeek) and hotel inventory (Top10) have been early Spreedly adopters: the concept of supporting affiliate sellers was already in place, so optimizing payments and checkout flow was the final piece of the puzzle for them.

The next wave of mobile apps, which startups like Wildcard are helping create, will only increase the desire from end users for a complete end to end search, share and buy within a singular experience. We look forward to helping solve the payments related challenges.

Spreedly’s Take on Apple Pay

For those of us in the payments industry, the announcement of Apple Pay in September was one of conflicting emotions. We found it both exciting and, yet, unfulfilling. Exciting in that it represented a compelling evolution of digital payments, but unfulfilling in that we had so many more questions than were answered in the initial announcement. How does it really work? How does it integrate with the existing card payment process? Can it be unlocked to work with any payment processor?

In the two months since that initial announcement, and the weeks since Apple Pay was actually released, Spreedly has learned a lot about Apple Pay. I’d like to give an update on our plans for supporting Apple Pay and why we’re excited about the opportunity.

How does Apple Pay work?

Much of Apple’s marketing around Apple Pay uses new or existing payment terms in non-standard ways. While this simplifies the consumer message, it makes it difficult to understand how the technology works. Now that we’ve had some time to dig deeper, we understand what’s going on beneath the covers and can talk in more detail about the process.

Apple Pay is unique to Apple and its devices. However, it is enabled by an existing payment specification called the EMV payment tokenization spec. This specification governs how real credit cards are turned into channel-specific alias numbers (PANs), which offer a greater level of fraud protection. Apple utilizes this tokenization process, while adding its own process for getting the alias PAN from the device to the merchant’s gateway.

You can visualize the payment flow, from when the card gets added to iOS’s Passbook through to the transaction hitting merchant account, as follows:

Please feel free to share this diagram

While Apple Pay represents a new, polished, consumer experience, it leans heavily on the existing EMV tokenization spec, which dictates how the alias credit card numbers are issued, identified and converted within the payment process. While it’s likely Apple had a hand in constructing this specification, it is not unique to Apple and can be used by other vendors.

What is unique to Apple Pay is how the payment token is constructed and the role of gateways in decrypting the payment token to expose the alias PAN. At the time of transaction, Apple uses the certificate provisioned by the merchant to encrypt the alias PAN and associated data. This encrypted token is then passed directly to a gateway that supports Apple Pay (and has the certificate’s private key) which knows how to decrypt and unpack the payment token. From this the gateway extracts the alias PAN, which looks just like a normal credit card number, and passes it off to the rest of the payment process for approval.

How will Spreedly support Apple Pay?

Spreedly is not a gateway. It is a credit card vault that integrates with dozens of gateways and other PCI-compliant APIs. So how can Spreedly play a role in the Apple Pay payment process?

If you’ll notice, the responsibilities of a gateway, as it relates to Apple Pay, are minimal. A gateway is really only doing two things: 1) Managing the private key associated with the iOS app’s certificate and 2) decrypting the payment token at transaction time to access the alias PAN. As it turns out, you don’t need to be a gateway to do those things.

If Spreedly assumes the role of the gateway solely in managing the Apple Pay certificate and decrypting the Apple Pay payment token, it can provide a single Apple Pay experience on top of any of the over 70 gateways we support. Additionally, because a payment token looks and acts like a real credit card number to the majority of the payment stack, it can be sent to non-gateway providers like ticketing, travel and other vertical APIs.

Notice how Spreedly’s support of Apple Pay differs only minimally from the conventional, gateway-specific, flow:

At Spreedly, we enable new payment technology across the widest range of payment targets possible, and that’s how we’re approaching Apple Pay.

When can I use Apple Pay on Spreedly?

For customers on one of our current pricing plans, we’re targeting a GA release in the first quarter of next year. We are already hard at work on it and have a few existing customers working with us as we move towards a private beta. If you would like to be included in the beta, please let us know. We’re always interested in understanding your specific use-case and hearing your feedback.

Parclick, Spreedly and Parking Apps

We see a lot of innovative startups in Spain interested in our platform. We also see one of the most difficult payment landscapes for startups to get started. Recently we’ve worked with CatalunyaCaixa to reduce the challenge of working with Spreedly and Redsys and today we share multiple customers. We hope other Spanish banks will soon follow their lead.

One of our newer customers is Parclick. Parclick was born in 2011 right after one of the founders missed half of a concert due to the lack of available parking spots. The founding team thought that people would like to book parking spots in advance just as they book hotels or flights. They launched three years ago and have been growing rapidly ever since. They help car park operators find and retain an attractive source of new revenue: long-stay customers. Drivers benefit too via cost saving parking offers and innovative parking products for both mobile and desktop. And everybody makes their concert in time!

While early traction was impressive, Parclick wanted to improve the payment experience. Put simply, sending customers off to a hosted payment page for payment impacted brand, flow, analytics and ultimately conversion. The goal was to continue to utilize in-country processing for improved credit card success rates and lower processing fees while creating an end to end Parclick payment experience.

“We found out about Spreedly through a friend, the CEO of another Startup that was implementing Spreedly at that time. He described what they were doing with Spreedly and it matched perfectly with what we wanted to do” said Luis Paris, CEO of Parclick.

Spreedly was shortlisted together with two other competitors, and selected after a month of testing.

“We chose Spreedly for several reasons. First, Spreedly had all security certificates we needed to operate payments safely for us and our customers. Next, Spreedly fit perfectly into our technological stack, allowing us easily to implement things like resilience processes for different payment gateway. Spreedly allowed us too to manage both desktop and mobile payments; and last, but not least, they were always ready to help when we needed them” said Ivan Rodriguez, Chief Business Development Officer.

“It took one month to get Spreedly into production, half of what we were expecting. And we are pleased with the performance and resilience of Spreedly; since we started using it we had zero downtime” Ivan added.

Spreedly has helped Parclick to improve their customer experience: “We at Parclick work tirelessly to improve customer experience, and owning the payment process was critical. This applies to using our own payment form that we can design, track and improve. Also to a seamless desktop/mobile payment process. And to easy recurrent payments without compromising our customer’s sensitive data” said Eduardo Layrisse, CMO.

“One very important thing that separates Spreedly from the pack is their prompt technical support, and their willingness to walk side-by-side with customers, to become a partner rather than a provider. This was key for our decision” added Luis Paris.

“Our next challenge is to integrate Spreedly with other payment processors such as Paypal”

Spreedly and track data beta program

One of the most popular buzzwords in the payments space right now is “Omnichannel”. Put simply, mobile devices have blurred the lines between a card not present transaction and a card present transaction (i.e. online vs in-store).  Spreedly has always focused exclusively on CNP transactions, but now we’re taking the first steps to support card present transactions.

One of the reasons we can do this is that many of the underlying gateways we support have added support for track data. As of November 2014, here’s a list of the gateways that we offer track data support for:

  • Authorize.net
  • Moneris
  • First Data
  • Network Merchants
  • Heartland Payment Systems
  • Pay Junction
  • Litle
  • Stripe
  • MerchantWare
  • USA ePay
  • Mercury

Today we’re announcing a beta program for support for track data. Please email support@spreedly.com if you’d like to learn more and/or be involved in the program.

 

Better Engineering Through Book Clubs

Culture is a hard thing to define. It has many layers, many facets, many manifestations and two people looking at the same practices might come to different conclusions about what it implies. Rather than wade into the choppy “what is culture” waters, we thought we could let you come to your own conclusions about the engineering culture here at Spreedly with a quick peek into something we’ve instituted recently – an engineering book club.

Here’s how it works at Spreedly: One of the engineers recommends a book, most often, but not limited to, a legit software development topic. Some recent examples include Distributed Systems for Fun and Profit and Release It!. Each week, after reading the same few chapters, we meet for an hour after lunch to discuss what we found interesting, what applies to Spreedly, anything we didn’t quite get etc…

This type of internal meetup has several benefits. First, it’s a no-pressure learning opportunity. You can interact with your peers and share ideas outside the normal operating environment which strengthens existing relationships and creates new ones. It also establishes the precedence that investing in yourself through continuing education is supported and even expected within the company. Couple the existence of a book club with the fact that reading for the club is encouraged during business hours and you quickly realize that the people are the priority here (much easier to say than to do).

Finally, diving into various engineering topics together allows us to take a moment to reflect on the direction of our production systems, outside the daily grind that can so often obscure this type of blue-sky thought. As a direct result of what we’ve read here at Spreedly we’ve all taken a much more involved role in increasing the resiliency of our systems and in providing operational visibility into its various components. We now also have a shared vocabulary when discussing the growth, operation and architecture of our systems which serve as building blocks for being able to more efficiently discuss complex topics. “Network partition”, “circuit breaker”, “bulkhead” and many others are now a common part of our engineering discussions.

Hopefully this sounds like something you might want to do at your company, if you’re not already. Here are some tips to get started:

  • Take initiative by suggesting a book. You can offer to change the topic later if there is support for something else. Waiting for consensus can be discouraging and time consuming so pick one to get the ball rolling. Choosing fun yet relevant material can go a long way to building critical mass to get the group going.
  • Figure out how supportive your organization is for the book club.  It can be a benefit to your company, so they may offer to “pay” for it by allowing you to use work time for your discussions. If that doesn’t work the next best option may be to schedule it during lunch.
  • It’s good to figure out the right pace.  Perhaps shoot for one meeting per week or every other week. Break up the book into manageable chunks. It is typical for us to finish a book in 4 to 6 sessions depending on the complexity and volume of material.
  • Encourage people to take notes of things they find interesting to help spark discussions. Point out any parts of the book that might be confusing or solicit questions of concepts that could use clarification. Having lively discussions will be important for maintaining the level of interest and the viability of the group.
  • Consider inviting outside participants. We’ve attended sessions where we had people from other nearby companies drop by. It livens up the conversation and keeps you from devolving into your company’s technical debt.
  • If having people buy their books is a financial concern, don’t forget about all the free technical content out there. There are quite a few blog series, videos and presentations online that can serve as the basis for your club.

There’s quite a bit more to Spreedly engineering than our book club, but we thought a quick peek into this one aspect would give you an appreciation for what we’re trying to accomplish here as we grow the team and build out our systems.

The Real Cost of Building and Maintaining Your Own Credit Card Vault

We often receive inquiries from potential customers who are looking for an independent credit card vault and are in the process of weighing up whether to use a third party service like Spreedly or build their own solution.  Given the importance of securely storing customer credit card data and the consequences of getting it wrong, the build-vs-buy choice represents a significant decision for any organization irrespective of size.  Like with most important strategic decisions, cost and time-to-implement play an important part in the decision-making process so we thought it would be helpful to break down what is involved in building a PCI-compliant credit card vault.

Human and Physical Resources

For many organizations the most significant costs in developing their own credit card vault relate to additional staffing and hardware requirements. To ensure the project doesn’t become a distraction to your core business, you’ll probably need at least one full-time employee to cover compliance, security, and the additional hardware maintenance required to maintain your own vault.  For companies with an existing compliance and security team, it may be possible to reallocate personnel to cover the additional workload. However for smaller organizations the need to hire at least one additional employee is likely unavoidable. The larger and more complex your needs, the more personnel you will require.  The additional staffing cost will depend on the market, but you can expect to spend at least an additional $70-100k a year on personnel costs.

Then there’s the additional hardware you will likely need to support your new credit card vault.  For a start you will need dedicated firewall, database, application, and utility servers together with all of the additional switches and hardware necessary to maintain your secure vault (including failover systems).  You’ll then also need to pay hosting fees for all the necessary hardware.  Total cost = $60-70k initial set-up with annual maintenance and upgrade costs of $40-60k.  Want geographic redundancy?  Double the cost.  Of course you can always elect to lease the necessary equipment, in which case you will be able to eliminate the bulk of the upfront purchase cost but as a consequence pay a higher annual fee of between $80-100k.

PCI Compliance

Perhaps the greatest unknown when it comes to storing credit card data is the PCI compliance gauntlet.  Elsewhere we’ve covered the process of becoming Level 1 compliant extensively and Spreedly’s own PCI compliance, and engaging with and working with a Qualified Security Assessor (QSA) is both a time and resource-intensive process that has the potential to create a huge distraction within an organization.  QSA’s quite rightfully take their responsibilities seriously and won’t sign off on a Report on Compliance (ROC) until they’re 100% satisfied that a company’s systems are fully-compliant.  There’s no doubt that the initial certification process is the most time-consuming and expensive step in the certification process, but every Level 1 PCI-compliant organization is required to undergo an annual re-evaluation by a QSA to confirm ongoing compliance.  QSA rates will vary and some estimates put the cost at $225k+ per year for many organizations, but in our experience smaller organizations can expect to pay between $35k-100k a year.

Insurance

An often ignored aspect of maintaining a credit card vault is the extra insurance you will need to carry to cover your organization in the event of a data breach.  Given the recent high profile Target and Neiman Marcus data breaches, credit card vaults are viewed as high risk prospects for insurance companies, which translates to them being expensive to insure.  The total cost will depend on the number of cards you plan to vault, the amount of coverage you require and your existing insurance relationship, but for a basic policy (e.g. $1-2 million coverage) it’s not unheard of to pay over $50k a year.  That will cover you for any fines issued by the card networks, security upgrades and your notification obligations to affected card holders.  These costs can quickly escalate for large scale breaches so insurance is a “must have”.

Technical Readiness

It is also important to consider is how technically prepared your organization is to handle credit card vaulting.  Probably the most significant factor to consider is what your code base looks like and whether you can easily isolate card storage/processing from it.  If you built your system with the idea of one day hosting your own PCI-compliant credit card vault and payment processing environment, then great, you’ve already overcome one of the largest technical hurdles.  If, on the other hand, you didn’t originally factor in the possibility of hosting your own vault then the process will be far more complicated, time intensive and perhaps most importantly – expensive.  If you’re fortunate and fall in the first bucket, then  you can expect to spend 2-4 months updating your code and developing the technical framework to support your vault, but if your code requires a serious overhaul it could take anywhere from 6-12 months before you’re ready to even engage a QSA.

Time to Market

There’s no hiding the fact that building a PCI-compliant credit card vault takes time – and a lot of it! Depending on your level of readiness you’re realistically looking at a minimum of 6 months if all goes smoothly to 12+ months if your QSA uncovers any issues that need to be rectified before they can certify your compliance.

Total Cost

All up, the average organization can expect to pay ~$200-340k to build an independent credit card vault with a 6-12 month timeframe, and annual maintenance costs within the same ballpark.

Of course the actual costs for each organization will differ based on their unique circumstances and geography, but hopefully this gives a rough estimate of the costs involved in building your own PCI compliant credit card vault.

Spreedly and Marketplaces

We consistently receive interest from developers looking to build a marketplace. We’re really only a good fit with one type of marketplace, which I’ll discuss below. First let’s talk about marketplaces overall. In many ways this post is an update to one we did a while back.

Defining a Marketplace 

There are 3 or 4 major functional components to a marketplace

  • Easily create a merchant account when onboarding a new seller to the marketplace
  • Take a percentage of each transaction as a fee while the transaction is occuring
  • Accept payments in the marketplace any way possible but mostly via credit cards
  • Pay out to sellers, once the money has been collected and the marketplace has taken its share, via ACH/bank transfer (cost savings)

Why are marketplaces so popular? 

The ease with with anyone can now accept credit cards (immediate onboarding) has allowed marketplace services to rapidly onboard all types of sellers that previously couldn’t accept online payments or were forced to only use PayPal as a payment method. What took someone like Etsy many months of development work can now be achieved in days.

Global

We should point out that right now, July 2014, no one is doing marketplaces globally. PayPal has adaptive payments (which we don’t support) but that is fairly complex and has never really taken off.  There are some good U.S focused offerings (Balanced PaymentsStripe and Braintree) and there is a rumor that PayPal is launching something soon that will be global. PayMill in Europe also talks about having marketplace support. However, these are very regional options. You can’t (easily) create a global marketplace today like you can a U.S one.

Spreedly as a marketplace offering

Spreedly has some characteristics that are useful for marketplaces. Card storage and tokenization means that once a buyer is set up in your marketplace they can buy from other vendors in your marketplace without re-entering data. Secondly, we support a wide range of global payment gateways. But our model differs in three critical ways:

Existing merchants. We service marketplaces where the majority of sellers already have a merchant account and expect to use that merchant account in your marketplace. That’s where our support for 60 + gateways/PSP’s comes in to play. Imagine a marketplace for beach rental properties. Chances are, people who already rent their beach house are accepting credit cards. If you’d like them to list in your marketplace it would help to let them keep using their primary merchant account.

That does not mean you can’t use us with someone like Stripe or Balanced to quickly enable new sellers who don’t have a merchant account. You just have to decide whether support for existing merchant accounts is going to be important to your marketplace. It’s certainly easier in many ways to not provide that choice.

No ACH disbursements: Due to the fact that your sellers have their own merchant account ACH disbursements are redundant. So we do not have support for ACH disbursements. One upside here is you’re free from the flow of funds and therefore the risk of chargebacks.

Revenue Model: Lastly, and this is the big one, we don’t support taking a % of the transaction unless the underlying gateway also supports it. Some like Balanced and Stripe do. However, most don’t. So it’s unlikely you can default to that model for how you get paid if you are using Spreedly. You could track the overall revenue and charge a seller separately on a transaction or monthly basis. Or you could just have a flat monthly fee to be in your marketplace.

So in summary, Spreedly is really only viable as a marketplace platform if you expect the majority of your sellers to already have, or easily get, their own merchant account and use it on your platform. Current industry trends might mean that’s going to be a more viable approach than a single vendor executing on a global strategy. Time will tell.

 

The Path to PCI Compliance

A number of years ago I was working on a product that enabled groups of people to communicate with one another and collaborate as a community – lets call it “AwesomeGroups”. We began to think there could be a revenue stream in features that allowed clubs and associations to collect membership dues or other monies. Here is what we thought we needed:

  1. Money should flow into the association’s bank account.
  2. Members must be able to use credit cards.
  3. We would host the payment flow ourselves.
  4. Credit cards had to be stored to enable recurring payments.

We looked at PayPal, Amazon Payments, and the like. None of those solutions were capable of helping us fulfill our plans. So we dove deeper into the details of collecting and storing credit cards, connecting to various payment gateways, and keeping track of all the transactions.

While there were many challenges we began to perceive, the one that concerned us the most was the collection and storage of credit cards. The costs of meeting the Data Security Standards of the Payment Card Industry were difficult to quantify. Everything we were reading led us to believe we would have to rethink every aspect of our system, including a move from our cloud host to a high security data center!

Missing the Forest for the Trees

The idiom “missing the forest for the trees” captures well the sense of what I experienced on that project. There were so many details surrounding compliance that we had missed the point of it all!

AwesomeGroups already had a custom payment form on it. Credit card information was sent to our servers, then forwarded to Authorize.net for storage and recurring billing of the monthy fees the associations paid to use the application. Somehow, we came away from our research with no idea that we had already placed ourselves in a position requiring us to be compliant with the PCI Data Security Standards!

The fact that escaped me then may be perfectly clear to you: if any part of your systems ever sees a credit card number, you are responsible for ensuring those solutions are compliant with PCI DSS. Credit card numbers are like gold, and the systems that request them and move them are like armored trucks – high value targets for the criminally minded. There may be mechanisms in your system which represent the weakest link in a chain of transacting. All a hacker need do is compromise your system and send to himself a copy of every credit card your program forwards to Braintree. You may never know it’s happening because you’ve done little to prevent it and nothing at all to detect it!

Perhaps you’re looking for the perspective I wish I’d had at the beginning of my research. The goal of this post is to help you step away from the trees and have a look at the forest.

Who’s Who

There are a number of entities involved in the processes that make the credit card payment ecosystem function. In the pursuit of understanding the world of PCI DSS, here are the most relevant:

  1. Merchants are people who sell stuff they make or services they provide. Most of them believe that they must take payment in forms other than cash. In the modern world, that means they must accept credit cards.
  2. Card Associations are known by brand names like Visa and Mastercard. These are networks of banks that issue credit cards (issuing banks) to customers and banks that provide merchants with the ability to charge a customer’s credit card (acquiring banks).
  3. Cardholders are customers who want to buy things from merchants. It’s super convenient to use a credit card. Cardholder data is the account number and sensitive authentication information, including the CVV code. Most customers believe this is more secure than carrying around cash. We all have an interest in making this as true as we can.
  4. Service Providers are the companies that provide card storage or processing products and services, whether to merchants or cardholders. Spreedly is a service provider, as are other companies such as Stripe. Payment gateways are service providers. Any company that makes Point of Sale systems (NCR, IBM) is a service provider. AwesomeGroups was a merchant, and could have been a service provider.
  5. Payment Application Developers and Integrators build and deploy hardware and software systems that merchants purchase to facilitate transactions using credit cards. These fall under the Payment Application Data Security Standard (PA-DSS). I list them here because merchants are encouraged to adopt solutions by these approved vendors, thereby easing their compliance burden.
  6. The Security Standards Council is made up of 5 major card associations. The council has produced the Data Security Standards as the representative requirements placed upon any other interested parties which process, store, or transmit credit card data, including companies that make hardware and software components for those purposes. In other words, they tell merchants, hardware manufacturers, application developers and integrators, and service providers what it means to secure the data owned by the card associations.
  7. Approved Companies are the organizations and people certified by the Security Standards Council to be expert in some aspect of bringing about the plans and verifying the implementations of the Data Security Standards. These folks know how to audit and test systems that process, store, or transmit credit card data.

Spreedly is a merchant and service provider. We are also a customer of a number of merchants that provide various services to us. Our platform interacts with payment gateways, which are service providers themselves, and must be PCI compliant. We are level one (L1) compliant, which means we know a good deal about the requirements set forth by the Security Standards Council, and we have engaged approved companies to assess our systems and provide regular scanning services. We are not considered a payment application developer or integrator because the solution we provide is not installed in an environment out of our control.

Scope

Scope refers to all of the components in your system that are subject to the requirements of the Data Security Standards. Scope refers to the collection of components – computers, routers, switches, physical or virtual – that process, store, or transmit cardholder data, known as the cardholder data environment, or CDE. Understanding scope when you begin to implement your solution is the same as buying an ounce of prevention. It is possible to build systems that cost substantially more under PCI DSS than others. More importantly, misunderstanding scope can lead to components which do not undergo proper care to protect your customer’s data.

If you have one computer serving a single HTML page, and that page contains a link to an offsite payment page, your scope is very small. You need only show that this single computer meets the requirements of PCI DSS. Imagine three networks comprising 20 computers which are somehow involved in the storage, processing, or transmission of card data – databases, log aggregators, application servers, load balancers, and more! If your system requires these components in order to implement the necessary cardholder data flow of your business, there’s not much you can do to reduce the scope.

On the other hand, you can expand your PCI DSS compliance scope unnecessarily by:

  • Granting access to the CDE to persons who do not need it. This would include anyone who is not responsible, in some way, for maintaining the components of the CDE.
  • Connecting components to the CDE that are not at all involved in the cardholder data flow, but grant access, in some form, to in-scope components. These systems must be as secure as any other in the CDE, and they will need to be maintained in a similar fashion.
  • Running unrelated software on in-scope components. These applications will undergo scrutiny, and they may expand the pool of people who have access to the CDE unnecessarily.

Every system can implement choices that dramatically increase or reduce it’s scope.

Online merchants can completely eliminate their scope by using a hosted shopping cart solution, such as Shopify. In this case, the merchant does not generate a single page of HTML, avoiding even the risk of having links to an external payment solution hijacked!

Both merchants and service providers can reduce their scope by outsourcing some aspects of their system to a PCI DSS compliant service provider. AwesomeGroups, if it had become a service provider to associations which wanted to accept dues from members, could have used Spreedly to store and process the cards, limiting its scope to the HTML page that presented the credit card form. Again, the application would still be subject to compliance requirements, but the validation of it’s compliance would be a much easier task.

As you become more acquainted with the DSS, you’ll agree that limiting your scope by having as few components as possible handling card data is a good thing, both in terms of reducing the risk of breach as well as the costs of maintaining PCI compliance. Check out this helpful guide as you further evaluate your scope concerns: http://itrevolution.com/pci-scoping-toolkit/

Levels of Compliance

Achieving compliance is the work of building a secure system with the smallest scope necessary. Assessing compliance, or validating compliance, can be accomplished through one of two paths:

  1. Complete a Self Assessment Questionnaire (SAQ). Someone in your business who understands the scope and implementation of your system will be a key player in doing this well.
  2. Engage a Qualified Security Assessor (QSA). These approved companies will figure out what is in scope, review the configuration and authentication controls of components, and interview people. They produce a very detailed Report on Compliance (ROC), which is intended to demonstrate the extent of their audit, recording their findings.

In either case, you will sign an Attestation of Compliance (AOC). This is a sworn statement that, to the best of your knowledge, your business processes, stores, or transmits cardholder data in a way that is 100% compliant with PCI DSS.

Which path should you take? PCI DSS compliance levels are not a measure of degree of compliance, but a guide to the path you must take to assess your compliance with PCI DSS. We have a table showing the compliance levels on our site where you can see that levels are determined by the scale of transaction activity in a business. Small online merchants processing 20,000 or fewer transactions per year are considered to be level four (L4) businesses. A large merchant clocks in at 6 million or more transactions per year, making them a level one (L1) business. Your transaction volume should inform you of your level, which will in turn direct you down the path to assessing your compliance with PCI DSS. However, note that according to documents from the Security Council, “Only the acquiring financial institution can assign a validation level to merchants.” If you’re a merchant, before you invest a lot of time on a particular path, it may be wise to ask your acquiring bank what level they assign to your business. Service providers may not have an acquiring bank and will simply work from transaction volume to choose the path to take.

L1 merchants and service providers must engage a QSA. While this is an expensive proposition, as it involves a lot of time and communication, you may be able to see why the card associations believe it’s a good idea to have someone validate your claim to be protecting all their gold! L2 and L3 merchants may need to do the same, according to the requirements of their acquiring bank. For instance, there may be certain types of businesses which represent a greater perceived risk of breach, or a business has failed to protect data in the past and must now be subject to greater accountability. However, many L2 and L3 merchants may self-assess, using the appropriate SAQ. All L4 merchants can use a SAQ.

There are a variety of Self Assessment Questionnaires because there are a variety of processing models. We have listed a categorization of the merchants on our site, showing which SAQ needs to be completed, depending on how a business uses various technologies – or does not use them – to process cardholder data. We would encourage you to read the guide provided by the Security Council, designed to help merchants determine which SAQ to use.

If you are a service provider, take note that you must use SAQ-D at levels 2, 3, and 4. This is the most thorough of the questionnaires. Service providers build technology that other businesses will use in their own PCI DSS compliant systems. Why not hold them to a higher accounting!

It may be tempting to pursue compliance at a level higher than your current transaction volume, believing you will one day supplant Amazon.com. You should delay the cost if your business is actually processing at a lower level. Nothing you do well for L4 is going to be a problem for L1.

Cost of Compliance

What most merchants and service providers really want to know when they get started is how much it’s going to cost to achieve and validate compliance. This is a function of both scope and the path of assessment as both of these factors impact nearly every other aspect of the cost, whether by increasing the number of components that need to be analyzed or the number of people involved. There’s no easy answer to the question of cost because no two businesses are the same, whether you look at their business model, management team, technology team, or current systems.

The best you can do at cost estimating, until you develop a record of compliance expenditures in your business, is ask Google. I can tell you from our experience at Spreedly, when I last looked at the search results, $225,000+ for L1 compliance is not unrealistic! Don’t forget, these are not one-time expenses. PCI DSS requires ongoing maintenance and annual re-scoping and re-assessment. Even small merchants, which must purchase and operate certified equipment in a compliant environment, can see costs far exceeding their expectations.

Conclusion

I can see in retrospect that we were right to be very concerned about the cost of implementing credit card storage solutions in AwesomeGroups. I’d like to think this post would have helped us to quickly understand what our responsibilities were as well as expose us to terminology that would have helped us imagine creative solutions our business could afford. We could have integrated with a PAN tokenization service like Spreedly, dramatically reducing our scope, thereby affording the opportunity to really explore the viability of the features we wanted to build.

Accepting Payments in Your Mobile App

Two trends are converging in technology that are changing consumer expectations and creating a wealth of blue ocean opportunities: the rise of mobile devices and the “Uberization” of payments. Everybody understands that mobile devices are now ubiquitous, but what is the “Uberization” of payments? Simply put, it’s the ability for consumers to conveniently and directly transact with other consumers and services, in real-time. Think of TaskRabbit which lets you quickly find somebody to help you with an errand, or, of course, Uber which lets you hail and pay for a cab from your phone with no hassle.

At their core, these services all enable effortless financial transactions between disparate parties via a mobile device. But when you are collecting payments, on any device, you must secure your users’ financial data and adhere to PCI compliance standards. PCI compliance is a nasty bag of vague requirements and becoming PCI certified can takes months of work even for a company that specializes in storing and processing credit card data.

So how do you correctly and securely develop a mobile application that touches financial data? Let’s walk through some common scenarios when developing a mobile app that accepts payments and evaluate your options.

Handle and store card data directly

If your organization is already PCI certified, congratulations! A lot of work has already been done to secure your existing systems and you may be able to receive and store card data yourself. However, a mobile app that touches card data exposes you to additional scope. You now need to work with your QSA to bring the app and supporting services in compliance. You know that this can take a huge amount of time and effort.

More likely your organization is not already PCI L1 compliant and wants to stay in compliance by minimizing scope wherever possible. You also want to be able to execute quickly on your concept. If so, the rest of this post investigates some more palatable options.

Existing mobile POSs

If you’re looking for a generic way to accept payments from consumers then you might want to consider a mobile point-of-sale app such as Square or PayPal Here. For a transaction fee (usually anywhere between 2.5% – 3%) you can begin swiping credit cards with negligible up-front cost and very little setup time.

This is a great option if you want to sell goods in a card-present environment such as a local marketplace or store. You don’t have to worry about PCI compliance and you get funds deposited to your account in a day or two. However, what you gain in ease of PCI compliance you lose in terms of brand and control. It’s a Square or PayPal driven environment vs your own brand.

If you want a branded payment experience, to distribute your own app, or operate in a card-not-present environment then these are not an option for you. Instead you should consider a gateway specific mobile component.

Mobile payment widgets

Many gateways offer mobile-specific libraries that make collecting payments within a mobile app trivial. These libraries provide their own payment UI components making the implementation as close to a drag and drop as can be expected in a custom app.

Major gateways such as Stripe, Braintree/Venmo Touch and PayPal all offer robust mobile libraries that do much of the heavy lifting for you. If you’re already using one of these gateways, or have yet to choose a gateway to process your payments, one that has a well-supported mobile SDK would be a good option. Card data is handled by their library, limiting your PCI compliance exposure and implementation effort.

There are only a few downsides to this approach: 1) You lose control of the UX since you’re using the gateway widget’s chosen look and feel and 2) Your stored payment information is locked into that one gateway, potentially constraining future provider decisions.

If you’re comfortable being a single-gateway merchant but want to provide a custom checkout experience or, in general, want greater control of the UX you will need to develop directly to the gateway’s API.

Gateway API

All relevant gateways support some form of a direct API that allow you to transact with credit card data. Integrating with these APIs depends on the implementation and client library support and can be delightful in some cases, and downright frustrating in most. However, beyond the developer experience, the more limiting factor is that you are now responsible for card data since it now passes through your mobile app.

There are many concerns you need to be aware of when directly handling protected card data. The first is that you are now in scope for requiring PCI compliance. If you are merely passing through this card data to a gateway for long term storage you may only have to complete a PCI self-assessment questionnaire.

There are also several security practices you should adhere to when developing a mobile app, including not bundling any secret passwords (such as gateway credentials or access secrets) with the app. Mobile devices are inherently compromiseable and any sensitive data stored on them should be considered at-risk. This can greatly complicate a gateway integration if the gateway doesn’t support an unauthenticated tokenization process that will let you store a payment method without requiring your API credentials for that specific step.

For example, collecting a credit card number with Stripe’s iOS bindings doesn’t require your secret API key, nor does Spreedly’s add payment method API call require your access secret. These calls will hand back a token representing the submitted card which you can then use from a secure and authenticated environment (e.g., your server environment) to execute actual purchase transactions. Many gateway APIs don’t provide this segmentation between storing a card from an insecure environment and transacting with it from a secure environment. This is required when accepting payments from a mobile app and should be part of your decision process.

Using a gateway’s API directly allows you complete control of the UX at the expense of increased development complexity and gateway lock-in. This latter point, the lock-in, is actually more relevant than you might think. For instance, to circle back around to Uber, consider a mobile app that has work with 10 cab companies in your city. This requires the ability to work with each taxi company’s merchant account which means you need to be able to operate across gateways. For this type of marketplace app you’ll need to consider a multi-gateway provider such as Spreedly.

Multi-gateway mobile access

If you want to collect payment information in your mobile app in a way that doesn’t lock you into a single gateway you’ll want to take a look at Spreedly. Spreedly uses a common API on top of dozens of gateways to provide a consistent payment processing language to your app.

Spreedly chooses to provide its mobile support via a two-phased tokenize/transact API that allows you complete control of the UX. Integrating with Spreedly from a mobile app requires the same attention to security as going to the gateway API directly, but provides the peace of mind of non-vendor specific card storage and processing paired with a modern, mobile-compatible API.

Mobile payment considerations

There is no one best choice when it comes to choosing how to accept payments in your mobile app – it all depends on your technology and business requirements. We’ve looked at a few different options, let’s compare them side by side to give you a clearer view of what approach is right for you.

Minimize PCI Scope Custom UX Ease of Implementation Multi-Gateway
Handle Card Data Yourself x x
Mobile POS x x
Mobile Payment Widget x x
Gateway Direct API x x
Multi-Gateway w/ Spreedly x

Though there may be some variance within each bucket, the general relationship between each option holds. For instance, the ease of implementation using a modern gateway’s direct API can be much greater than using a poorly implemented and documented payment component. However, in general, it is more effort to integrate directly to a gateway’s API than to drop-in their mobile-specific widget.

As with any decision, choosing how to best accept payments in your mobile app is a balancing act. There are several options, all that have their own pros and cons. We hope this post serves as a useful roadmap to that decision.

“Merge pull request” Considered Harmful

Merge pull request button

I love Github – I think it’s made contributing to open source 1000% more approachable and enjoyable. But I’ve found the open source maintainer workflow that Github puts front and center in the form of the web Pull Request UI is actively harmful to project quality and speed of taking contributions. So before you hit that big old “Merge pull request” button on the next open source Github Pull Request you think is deserving of inclusion, let me tell you a quick story.

Meet the Maintainer

Lots of Pull Requests

Jane’s the maintainer on a modestly successful open source project. She gets a couple new Issues opened on her project’s Github repo every week, and she’s quick to dive in and provide feedback on the requests coming in. While she doesn’t have time to implement all the good ideas, she does try to give folks a quick thumbsup or thumbsdown so that they can code them up and open a Pull Request for inclusion.

As all good maintainers do, she has written up a CONTRIBUTING document, and of course her repo has a README and a CHANGELOG that get updated as the project moves forward. There are a couple levels of automated tests that contributors can run as they develop and are expected to extend as they add features. Jane has even adopted a comprehensive public style guide so that the code base will stay tidy.

As conscientous as she tries to be, though, Jane has a problem: there are over a dozen unmerged Pull Requests on her repo! And she feels like she’s always behind on getting them merged, even though a lot of them are pretty straightforward. Looking over them, a couple are awaiting large revisions based on feedback, but the vast majority are stuck on small stuff: an extra test that needs to be added, a few whitespace changes to match the style guide, a missing CHANGELOG entry, a bunch of commits that need to be squashed, etc.

What’s even more frustrating is that even though Jane provides feedback quickly, often contributors lose interest and/or forget about taking their Pull Requests the final step after initially contributing them. The apparent triviality of the changes Jane’s asking for (somewhat perversely) contributes to that loss of interest, since it just feels like nit-picking when she’s asking for the fifth overlooked stylistic change.

What’s the end result? All kinds of unmerged “code inventory” sitting around taking up mental space. Jane’s frustrated and losing motivation, and the current crop of contributors are less likely to show up again in the future.

Git as Linus Wrote It

Linus

Hello, my name is Nathaniel, and once I was in the same spot as Jane. I’d recently jumped onto the ActiveMerchant project, and it had pages of Pull Request inventory stuck on trivial stuff. I knew exactly what needed to get done for most of them, and I was stuck with two options:

  1. Hope that original contributors show back up to finish cleaning up their contributions so they can be merged cleanly.
  2. Merge contributions that aren’t quite ready, then do another commit to clean them up.

Unfortunately, neither of these paths is very appealing. I tried the former for a while, giving contributors detailed feedback and waiting for them to incorporate it. Most of the Pull Requests just kept sitting there, staring at me. And I ended up trying to teach advanced git to a bunch of people: “Can you squash out your five WIP commits?” “Isn’t zucchini a squash?”

The latter option results in weird historical states, the possibility of non-working intermediate code breaking git bisect, and if the cleanup takes a while to get to future Pull Requests could be based off the not-quite-ready commit or commits. Or the clean up might just get forgotten. I tried it once or twice, but it was super painful and my OCD couldn’t deal with the results.

So, what’s the solution? Turns out git was built to make this situation easy to deal with, and the only thing that was really holding me back was the workflow that Github puts front and center. So I stopped using the “Merge pull request” button, and instead I now do this:

  1. Install hub.
  2. Grab the Pull Request url. Looks like “https://github.com/Shopify/active_merchant/pull/1259″.
  3. In the repo, on the master branch, I run git am -3 <url>, where url is the Pull Request url. Conflicts? I fix ’em and then git am --continue.
  4. Now I have the changes applied right in my local master branch. I make fixes, clean up whitespace, add a line to the CHANGELOG, tack on tests, etc. The world is my oyster.

I’m not done yet – I still need to prep the changes to be pushed – but before I go on I want to highlight what I’ve done here. Git has a built in tool called am (stands for “apply mail”) that is designed to slurp up incoming patches out of an email inbox. The handy hub tool from Github adapts git am to work with web hosted patches, specifically the raw patch you can get for any Pull Request. So by using this workflow, I’m hewing much closer to the workflow the kernel maintainers (for instance) use when reviewing and merging patches.

History Is Written By the Victors

Choose Your Own Adventure Book

So now I have perfect code (hello hyperbole) sitting in my local master branch, with all the contributed commits showing up in git log, and my changes uncommitted. What comes next is a bit of a “Choose Your Own Adventure” situation, since it depends on what I’m working with:

  • If the contribution is a single commit, I’ll do a git commit --amend and just smoosh my changes right into the original commit.
  • If the contribution is multiple “work in progress” commits, I’ll commit my changes and then git rebase -i origin/master to squash all the commits including my own into a single logical commit.
  • It’s rare in my experience, but if the contribution is multiple logical commits that are “history worthy” in terms of being incremental steps that make sense in isolation, I’ll add my commit at the end.

Now I have the contribution ready to go, and there’s just one more little trick that makes it even more awesome: I add Closes #XXX. as the last line of the commit message, and when I git push the Pull Request auto-closes. Even cooler? If the Pull Request is open in my browser, the browser automatically updates to reflect the Pull Request being closed. Github, you so smart.

Here’s what the commit history looks like on the ActiveMerchant project:

Recent ActiveMerchant commit history

Compare that to the Rails commit history:

Recent Rails commit history

I know which I prefer. And what’s even better is that I’m now spending way less time going around and around with contributors and way more time merging code. Final bonus: if you notice in the ActiveMerchant history, the contributors still get all the credit for the commits, regardless of how much editing and/or rebasing of them I did of them. That’s just how I roll.

That Pesky Button

Merge pull request button

When might you still want to use the “Merge pull request” button?

  • Super small changes – think one-liner doc only tweaks. That said I’ve stopped even doing this since it’s just plain ugly, and it doesn’t take much longer to do it “right”.
  • Internal/private projects – do what you want. I have no idea what your situation is, or what makes sense. Personally I still prefer a clean commit history.

But what are the benefits of not using the “Merge pull request” button?

  • Contributors don’t have to get every detail exactly right.
  • It’s easy as a maintainer to clean up commits.
  • Less posting/emailing and more coding.
  • Commit history becomes a useful story that’s a joy to read.

I’m a big fan of the benefits, and my experience is that it means less time and less frustration for me as a maintainer. “Just push a button to take contributions” sounds great in theory, but in reality it adds friction that makes my job as a maintainer harder.

And as a hypothetical story-telling construct I created in my mind, Jane agrees 100%!

Payment Gateway Index for May 2014

Hi everyone,

Data for May is now available at the Payment Gateway Index.

In terms of gateways with the most volume Orbital, First Data and eWay all cracked 90% success or better. It was also good to see Authorize.Net back above 80% success rate.

Orbital was also again the most responsive API (at least as it relates to Spreedly and Shopify) amongst those gateways where we see the most volume. Litle though has the best overall rate and improved even more in terms of responsiveness in May (set both axis to “Success Rate” and click the Litle box on the right hand side here to track performance over time).

Team Spreedly

(as always thanks to Shopify for pooling the data with us).

GUEST BLOG, Part IV: How online merchants can recapture revenue lost to declines

By David GoodaleMerchant Accounts.ca

If there is one singular, critical best practice as it relates to declined transactions, it is to monitor your website traffic for clickoffs. (If I am not stating that strongly enough I might re-word myself by stating it’s critically, incredibly important to monitor all website clickoffs, especially at the order form.)

We have to keep in mind that the card issuing bank has ultimate control. The card issuer has the ability to decline any transaction, at any time. Because of that, it means that you, the merchant, must implement a reactive process to deal with this.

In other words, you need to be on the ball, catch a decline when it happens, and get in touch with that customer to recover the lost sale.

This must be done by capturing customer data before it is sent to the payment gateway to be processed.

Then, if the order does not proceed you can have a staff member reach out to that prospect to find out why they did not proceed. You can also cross reference your records ahead of contacting the customer to see if the reason for the abandonment was a declined transaction.

For an example, at Merchant Accounts.ca we provide credit card processing services. This requires an application process in order to get approved. Sometimes people click off because the application asks for something they don’t have on hand at the time (like their business registration number). In other cases, they might have tried to submit payment for the setup fee and had their credit card declined for any of the reasons mentioned in this article. In all of these situations we reach out to the customer to find out what went wrong and help them continue with the application.

As a salesperson you don’t want to lose an opportunity. That is why we collect this information before the customer is sent to the payment gateway. We get an email that is very similar to the “Order Approved” email, except that it is the “Sent to Gateway” email. That way we can easily follow up if the customer does not proceed.

In some cases, due to the nature of an integration (for example, if you are using a transparent redirect or javascript to encode cardholder data) this may be more difficult to accomplish. If possible, try to structure your form so that two requests occur on a single button click by the user. The initial request could be an AJAX request that is sent to your server (but without any cardholder data), is parsed and stored/emailed to your sales team. Immediately after, the transaction request is rebuilt and immediately sent onto the payment gateway as normal. This is never intrusive to the cardholder because it happens instantly, and they cannot see it occur. With a little ingenuity it should be possible –and while more work–can help significantly increase sales.

If your integration cannot allow for this, another good idea is to use the reporting on your payment gateway. You should be able to construct reports of all declined transactions, and can reach out to those cardholders to see what went wrong.

The reason why this is important is because it is the business owners’ job to hold the door wide open for your customers. Make purchasing easy, and don’t be afraid to reach out to a customer, even if they clicked off. There are even more reasons for doing this beyond declines, which are beyond the scope of this discussion. Suffice to say that if you reach out and speak to your customers and prospective customers, it’s almost impossible to walk away with anything but useful feedback that will help improve your business.

Summary

Declines are inevitable. With that being said, some businesses will be more prone to declined transactions than others. For example, if your business sells very expensive products, or if you sell to a high percentage of foreign customers, you will see more declines than business selling an inexpensive product to local customers.

It simply hurts to have an otherwise hard-won customer and lose them over something as simple as a declined payment. The good news—even if your business does happen to be prone to declined payments, by understanding the reasons why declines happen, you can build processes to catch it when it occurs. With a knowledgeable and well-trained customer service staff, you can confidently reach out to help your customers–reversing declined transactions and turning them into sales.

About the Author

This article was written by David Goodale, CEO at Merchant Accounts.ca. David has over 12 years of industry expertise in the field of credit card processing, specializing in the area of cross border and multi-currency e-commerce payments.

Merchant Accounts.ca is one of Canada’s longest established credit card processors. In particular, Merchant Accounts.ca specializes in multi-currency credit card processing and is able to help businesses transact in many different currencies such as CAD, USD, GBP, EUR, AUD and JPY. With a client-focused approach, each merchant works with the same dedicated account manager for the lifetime of the account. This consultancy model helps to make it much easier and faster when launching an e-commerce project, no matter the scale, number of currencies, or territories involved.