Spreedly Blog

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.

 

3-D Secure rates by country in Europe

3-D Secure is a controversial online fraud management tool. It’s controversial in that it’s enforced in an ad hoc manner country to country. It is implemented differently on a gateway by gateway basis and it breaks the flow of optimizing for conversion. It’s also something that gateway’s or PSP’s need to enforce but it’s usually mandated on the merchant by the acquiring banks. More than one merchant has been told it’s mandatory only to push back and find out it can be disabled.

Ogone just published a short PDF on their Flex 3DS offering (The 4 page PDF is here). As you know from the payment gateway index we are big believers in sharing data so we are glad Ogone has shared this. For now I’d just like to share their European country by country view. As you can see, adoption rates vary greatly within Europe. This might be helpful for those merchants who feel like 3-D Secure is being forced on them by their acquiring bank.

Thanks Ogone for sharing this.

 

Ogone3DSimage

GUEST BLOG, Part III: Why card issuers decline transactions and what to do about it

By David GoodaleMerchant Accounts.ca

Humans are habitual and have patterns that can be observed. This may or may not be considered an invasion of privacy, but in the world of card issuing it is fortunate in that it can help a card issuer detect unusual activity for a particular cardholder.

For example, a bank may have issued a credit card to a senior citizen. This senior citizen may have been a cardholder for more than 10 years, using the card an average of three times per month. These purchases might always be less than 100 dollars, and always local to where the cardholder lives. In this example, the card may have not ever been used in an online (card not present) scenario before. If that same credit card was suddenly charged for 10,000 dollars at an online casino website based in the Caribbean, it would be an obvious trigger to suspicious activity. This would almost certainly be picked up by the card issuing bank and blocked. The trick for the card issuing bank is to implement protections for the cardholder that will protect them in less obvious situations, while not overly inconveniencing the cardholder from doing what they want with their card on a day-to-day basis.

Each card issuing bank will protect its algorithm used to prevent and defeat fraud. Releasing such information would only empower fraudsters and help them bypass such protections. However, we can examine some of the more obvious checks and balances that card issuers employ to protect cardholders.

Insufficient funds:  This is the obvious cause of a decline. In some cases the cardholder may have been spending more freely than he had realized, and the card balance may simply be over its limit.

Expired card:  Another obvious reason for a decline. If the card is expired the card issuer will probably decline the transaction. However, it is worth noting that a card issuer actually can still approve a credit card with an expiry date that has elapsed.

History of international purchases: If a cardholder has never purchased outside of a geographic region before and suddenly does so for the first time, it could be an indicator of a stolen card.

History of online purchases: If a cardholder has never purchased online before and suddenly does so it could be an indicator of a stolen card.

Transaction size limits:  If a cardholder has never used their credit card for a big ticket purchase before and does so for the first time, it could be an indicator of a stolen card.

Multiple purchases from different locations at the same time:  If a cardholder is using a credit card in Toronto, Ontario, in the morning it makes sense that she can’t also be using the same card in Miami, Florida, later the same morning. This is a strong indicator of a stolen credit card (and is also why you should always notify your bank if you will be traveling. Otherwise you may find your card blocked!)

Card has been determined or reported stolen:  Card issuing banks must react quickly to stop fraudsters and protect cardholders. In some situations a credit card may have been determined to have been compromised, and the card issuer will put a block on the card even before notifying the card holder. In these cases a phone call will usually be placed to notify the cardholder, and a new card shipped out.

In contrast to what we are discussing in this article, in rare situations some merchants actually want to assume transactions are good and not submit them to be processed in real time, but wait and batch them out later at a less busy time.

This may sound like the height of insanity, but let’s explore with an example. A very large chain retailer might establish a limit on certain card types during the holiday season to just approve transactions under 10 dollars. Why would a merchant ever assume a card is good?  In the holiday season, if a very large merchant has hundreds of stores with thousands of POS machines, they could be hammering a processing platform, which could cause a backlog or instability on the network. The real issue though is not so much technical but human in nature. The retailer wants the lines short to speed sales through. If a retailer can get more sales done during business hours, it may be worth the relatively small chance of a declined order when batching later to keep customers zipping through the checkout. Another example of this could be on an airline in which you purchase a sandwich, but the POS machine cannot establish an internet connection during flight. Logic stands to reason that if you can afford a flight that you can afford a sandwich on the journey. There are cases in which it’s not worth risking a decline in order to get more business put through the system.

What to do when you think a card issuing bank is declining a transaction?

Whenever a transaction is being declined by a card issuer the solution is always the same. There’s very little that you as the merchant can do despite the cardholder protesting to you that his card, “…should be working!” The cardholder must contact his card issuing bank to determine why the transaction is being declined. The cardholder should start by asking if the transaction in question can be seen on the system. (That way we can make sure the bank is seeing the transaction and it is not a gateway-side error). If the bank responds in the affirmative, the cardholder must ask if the transaction was blocked by the bank. If so, he must ask for the bank to release the block. At that point the cardholder can re-attempt the transaction and it will be successful. (In the next  post in this series, I’ll cover best practices that will help you recover lost sales in the event of card issuer declines.)

Other reasons credit card transactions can be declined

If you think of the payment process as a chain of events, there are several “handshakes” that must occur in order for a transaction to complete. If any one of these parties in the chain is down, interrupted or unavailable during the transaction resolution, a problem will occur.

The process starts at the payment gateway. The payment gateway will send transaction information to the processor. The processor handles the batching of transaction data and settlement files over the Visa and MasterCard network to the card issuers. This is a potential point of failure.

Another point of failure is the card issuer itself. If the card issuer is down a transaction can be declined. In some cases the card brands themselves may intercede to provide network continuity and approve or decline transactions to prevent downtime. The card brand, if standing in to approve a transaction does not have as much information as the card issuer, so this could still result in declines because it may implement a lowered maximum transaction limit cap during this window of downtime.

The card networks and card issuers realize that uptime is critical. Such service interruptions are rare. In fact, Visa and MasterCard maintain a systems freeze during the months leading up to Christmas in order to minimize the chances of downtime occurring due to system glitches or human errors. However, no matter how redundant a system is, downtime can occur. That is why it is best to have a procedure in place to monitor declines and try to recapture lost sales. We’ll cover that in the next and final post in this series.

 

GUEST BLOG, Part II: Reducing declines on the payment gateway side

By David GoodaleMerchant Accounts.ca

In part I of this series, “Everything online merchants should know about credit card declines,” we looked at the causes of declines and how to minimize them on the card issuer side. Unlike card-issuer side declines, as a merchant you should have a significant amount of control in terms of the anti-fraud settings within your payment gateway.

Making certain that the anti-fraud rules are configured correctly for your type of business is important and can make a big impact on sales (as well as cut down on fraudulent orders significantly).

It’s worth noting that some payment gateways may offer more or less functionality when it comes to the anti-fraud settings that are available in your control panel. You will have to explore to see what options are available with your chosen credit card processor. Ideally, you would like your payment gateway to be configurable to take the following actions when a potentially fraudulent order is detected:

   i)  Ignore:  Do nothing.

  ii)  Flag:  Warn you when a suspicious order comes through, but take no action to decline.

 iii)  Decline:  Do not let the transaction be approved, and decline the order.

Every payment gateway will have its own set of anti-fraud rules. Some payment gateways have more advanced anti-fraud detection than others. It’s also worth noting that some payment gateways may provide sophisticated fraud detection routines, but they may not be configurable by merchants. (For example, a velocity check filter may be supported, but it may not be adjustable on the number of hits within the elapsed period of time before a trigger is tripped.)

You will have to contact your credit card processor to see what anti-fraud tools are supported within your payment gateway.

Below are some of the most common anti-fraud checks: 

Velocity checks by card number: Will determine how many times a particular credit card has been processed within a certain window of time, for example, daily. If the same credit card number has been processed over and over again in a relatively small space of time, it can be an indicator of fraudulent activity.

Velocity checks by IP address:  Similar to the velocity checks on the card number, the velocity check on the IP address checks to see how many times a particular IP address has been used to perform a transaction within a certain window of time. If the same IP is used to submit three or four different credit cards within a short window of time, there is a high likelihood of fraudsters attempting to run transactions on stolen cards. However, IP checks are not perfect, because website visitors from some networks may share IP addresses, which could potentially cause false negatives. Unless you sell a particularly high risk product or service, you might want to set your velocity checks to flag but not decline.

Geographic location transaction blocking: Some areas of the world have higher incidences of fraud than other territories. For example, some developing nations do not have significant enough police resources to be able to crack down on fraud. Transactions originating in these territories are far more likely to have a greater potential risk of fraud.

Decline on mismatched CVV:  Some payment gateways will enable you to decline an order if the CVV number (the three-digit code on the back of the card) does not match. In general, unless you have a particularly high risk product or service it is best to flag these orders for further investigation, but not decline them outright.

Decline on mismatched AVS:  Similar to CVV-based declines, some payment gateways will enable you to decline orders in the case of mismatched AVS. I strongly recommend setting this to flag-only because of issues with international orders (where AVS may not be properly supported) resulting in false negatives.

 

How “air tight” should my anti-fraud rules be configured?

As a merchant you must take responsibility for protecting your own best interests. In other words, do not ever process a suspect order and ship it while hoping for the best. At the same time, you do not want to be overly restrictive and inconvenience your customers when it is not necessary.

Depending on the risk associated with your product or service you will want your anti-fraud settings to be more stringent, or a bit looser. For example, a merchant selling digital access to immediately download expensive software after payment (something like Adobe Photoshop) would have a much higher likelihood of attracting fraudsters than a merchant selling a physical product like knitting books. In fact, the knitting books example is less risky for two reasons:  (i) it is a physical good that must be shipped and cannot provide the fraudster with immediate gratification; (ii) knitting books are likely to appeal to an older demographic that is less likely to commit online fraud.

I cannot think of any cases off the top of my head where I have ever encouraged a merchant to disable the fraud rules entirely. Similarly, there are relatively few times when I have encouraged a merchant to set a fraud rule to automatically decline in the case of something mismatching, like AVS. In most cases, it is best to use anti-fraud rules to “flag” an order, so that it comes up on the radar and can be manually reviewed. An example of when you might set an anti-fraud filter to hard decline would be in the case of a product that can only ship within Canada. In that example, if the IP address showed the cardholder was located in Africa, it might make sense to automatically decline. However, situations like this are few and far between. It is better to let the order to through, at least as a pre-authorization, and give it the benefit of the doubt to at least allow for manual validation. Generally speaking, you do not want to lose sales unnecessarily because of an anti-fraud rule that is overly restrictive.

In the next post in this series, we’ll address reasons why card issuers decline transactions.

Spreedly at Finovate Spring

A couple of weeks back we had the opportunity to announce and demo our new Payment Method Distribution functionality at Finovate in San Jose, CA.  The two-day event allowed innovative Fintech companies to demo new products to an audience of Silicon Valley start-ups, VCs, press and various service providers.

Demoing an API is not an easy task, so to spare the audience from a long and potentially boring technical deep-dive we decided to highlight a real-world example of our PMD functionality in action. Seat Geek kindly stepped up to the plate and put together a live demo site for us to show how PMD has changed their payment flow and improved their customer checkout experience.  By showing the audience a “before-and-after” ticket purchase, we were able to demonstrate how the PMD functionality allowed Seat Geek to redesign its checkout experience so that customers remain within its environment for the duration of the purchase process, thus reducing drop-off rates and increasing the amount of customer data captured and retained by Seat Geek.  You can watch the entire demo here.

Finovate also highlighted some other cool emerging payment technologies, particularly in the mobile wallet space. Loop demoed their new streamlined magnetic “loop” that they claim will be integrated into a number of leading handsets over the next 12 months creating a new type of mobile wallet and payment method, while Wipit announced a new, low-cost way for the underbanked to send money to friends and family around the world across the Boost Mobile network.  Another cool feature that was presented at Finovate was Jumio’s card and ID scanner, which allows users to quickly capture their credit card details or photo ID via an app on their phone for a range of uses.

Killing redirect payment pages for meta search sites

We’ve all experienced what it’s like to get re-directed from one site to another to make a payment. In many parts of the world this is still the default payment process offered by payment gateways. Benefits include the fact that none of the processing occurs on the merchant site thus reducing the risk around storing and transacting credit cards, but the downsides are also obvious: you send away a prospective customer at the most critical point in the process.

Newer payment gateways/PSP’s have made the hosted payment page (HPP) all but a distant memory in countries like the US. Javascript and transparent redirects provide the benefits of not handling sensitive data without sacrificing end to end control of the process. Ongoing global expansion of services like Stripe and Braintree combined with new in-country solutions mean that trend will only continue to spread. Spreedly, while not a payment processor, also supports the concept in a number of ways across all of the gateways that we support.

This offsite experience is still very much alive when it comes to meta/vertical search and affiliate-based online commerce, though. Sites like Hipmunk invest a significant amount of time and energy searching multiple API’s to return a full range of results for an upcoming airline or hotel. They then add another layer of benefit by ranking those results based on a full range of parameters to make recommendations. The end user hits “buy” and… is redirected to another site to complete the transaction. There’s a completely new UI/UX look and feel. You’re forced to enter your card data in that cart/shopping experience. Occasionally you even receive an error when hitting that third party page.

It’s not hard to imagine how this creates a significant drag on conversion hurting all three parties. Wouldn’t it be great to never leave Hipmunk to do that?

Spreedly has solved this problem with our new Payment Method Distribution. SeatGeek is a new Spreedly customer who helped us during our beta implementation and is now rolling Spreedly out across their site over the month of May 2014. Here’s their homepage where you can search for event tickets:

SeakGeek

 

Next we look at SeatGeek’s value add today. You can see that they’ve searched a range of different API’s, presented prices, added a nice stadium map and rated deals based on how attractive they think it is:

Stadiumticketslayout

But as soon as you select one of the pricing buttons you face the infamous redirect:

Redirect

This process still works, but it creates so many new dependencies to completing the sale that it negatively impacts close rates. It’s a completely different design flow and a new trust equation. It’s also frustrating to spend so much time optimizing your own site only to then hand off to a third party who doesn’t share your same design philosophies (You’ll notice the completely different look and feel of the Prime Sport page to the original SeatGeek site)

PaymentPage

Now, let’s see what happens with one of the partners where they’ve leveraged Spreedly’s Payment Method Distribution. You hit the blue button to purchase the tickets and…

Post Spreedly

Shazzzam! You’re still within the SeatGeek environment solving one of the hardest challenges around meta ticket sites.

One of the nice things about Spreedly is that we allow SeatGeek to store payment methods. They could try and store those payment methods themselves but they’d be looking at 6 – 12 months and $50,000 to $100,000 in PCI certification and compliance costs. They could also try and store them at a payment gateway like Stripe or Braintree and avoid the PCI compliance costs but that means the card is locked at that particular gateway and cannot be easily used to transact against other gateways. There’s also no way they can retrieve it and pass it to a third party API.  Spreedly, however, allows them to store it once and pass it multiple times to multiple different end points over time.

Once SeatGeek has stored a payment method with Spreedly we return a credit card token to them. The second piece of good news is that they can retain this data on behalf of the customer in case of future purchases eliminating the need for that customer to re-enter their card data. This increases the likelihood of repeat transactions on the SeatGeek site by reducing the friction in the checkout process for subsequent purchases.

The final step in the process once the customer submits an order is for SeatGeek to route the request to Spreedly along with the credit card token by writing to a predefined template. We attach the underlying credit card data and pass all of the information along to the API endpoint (developer docs for those interested in greater specifics).

It’s important to note that the order flow has not changed from a typical gateway transaction. The actual card charge still occurs at the end point API. What’s really changed is that a) SeatGeek has retained the customer CC information and b) the customer is not sent off to another site to manually input all of the above information. They stay with SeatGeek and are updated upon success (or failure too).

The end user wins because they only enter their card information once on the same site vs visiting two or more sites to complete a transaction. SeatGeek wins by building loyalty and a repeat purchase situation while also controlling the end-to-end user experience. The end point/third party API wins because SeatGeek increases chances of a successful purchase. Even the card networks win as Spreedly is reducing the actual number of locations that a card can be stored and gives third party services like SeatGeek a secure and easy way to implement what they need.

Busbud is another Spreedly customer using Payment Method Distribution. Interestingly, they have a blended model whereby in some cases they simply drop in the payment gateway credentials for customers and transact directly against the merchant account. But if that’s not possible (usually because the endpoint won’t share their gateway credentials) they can now transact against the exposed API instead.

There are no doubt many other interesting use cases for our Payment Method Distribution functionality. We’re excited by the potential to help meta search and affiliate sites improve the commerce experience for all the key participants.

P.S Thanks so much to Eric Waller, SeatGeek’s CTO, who was instrumental in helping us launch this new offering.

 

 

 

 

Security Update: The Heartbleed Bug

A vulnerability known as The Heartbleed Bug was discovered in recent versions of OpenSSL. You may already be aware that this library is used by a substantial number of services on the Internet. We use it at Spreedly. We’re happy to report that we have deployed the changes necessary to mitigate the vulnerability.

We have taken the precautionary step of deleting all browser sessions. We want to recommend that you consider taking the following steps:

  1. Reset your Spreedly password.
  2. Generate new Access Secrets. These are used by your applications to connect to our service.
  3. Generate a new Signing Secret. These are used by Spreedly to sign requests made to your servers when working with offsite gateways.

If you need assistance, please contact us at support@spreedly.com.

Thank you for using Spreedly!

Visual: Credit card success and decline rates changing over time

In September 2013 we launched the payment gateway index (PGI) with help from Shopify. 

Each month since we’ve updated the page to present the latest data on a static page. Over time we saw large changes for some gateways.  Some large enough to make us question whether we had broken something on our end. Yet customer’s confirmed via conversations with their gateways that fraud filters at times were turned too high and were subsequently adjusted.

So we created a view that showed changes over time. In fact, we created a couple of different views. Today we’re announcing PGI “Labs” to allow you to explore the data and watch change over time. For Spreedly customers we’re going to look to ways where we can start giving you more “real time” notifications – most likely in the second half of the year. You could then engage your payment gateway in real time and/or route traffic through another payment gateway until the situation settles down.

We hope you find it valuable. We’ve just updated it with the most recent data from March 2014.

 

JSON and JSONP Support

Spreedly has just made support for JSONP publicly available for adding payment methods. While we have had support for CORS for some time now, the addition of JSONP improves options for developers.

The transparent redirect is still a great places to get started for adding payment methods with Spreedly. It is a simple form that doesn’t require any custom client side code. However your needs may be more advanced. For example, you may have a single page app that needs to remain active so you don’t want a page refresh. CORS and JSONP can give you that flexibility by using JavaScript’s asynchronous request capabilities.

We’ve also updated our documentation for CORS to use JSON as the data type rather than XML since it is the natural choice for web and mobile apps. Rest assured that XML will remain fully supported.

If you choose to do mobile development in a native language with a networking library, you can choose to directly add payment methods. It is an endpoint that is friendly to JSON that you can work with directly for creating payment method tokens.

With all of these options to choose from, it can take a little bit of analysis to choose which one is best for your needs. Our adding payment methods page outlines the different options and assists you in making a decision.

SAQ-A-EP: A big shakeup for online merchants

EDIT: This post was originally made in March 2014. In April 2014 an “Understanding guidelines” doc was issued that indicated that iFrame pages would be treated more favorably than direct post/redirect approaches. It’s still fluid so stay tuned.

 

The new PCI DSS 3.0 Self Assessment Questionnaires (SAQ) were released recently but will not go into effect until January 2015. However, as the new requirements stand, the impact for merchants transacting online seems to be potentially very significant.

Up until now, many payment gateways (or PSP’s) have offered a hosted payment page for smaller merchants. In return for using a hosted payment page the merchant was only required to complete a SAQ-A (about 13 questions in length). It now looks like merchants who use hosted payment pages will be required to fill out a SAQ-A-EP. This is 139 questions long or 10x the length of the old form! It looks like there will be more than 100+ technical controls for any merchant to validate. They’ll also have to do a quarterly scan and an annual penetration test against their site. For smaller merchants that’s a significant jump in both time and cost.

To be clear, this applies to merchant who host (or use a third party) to host their site and then hand their customers off to a hosted payment page (HPP) for completion of the order. What the PCI SSC is effectively saying here is that bad guys can take over that hosted site and redirect the HPP to a location of their choosing and therefore capture the card details. So your hosted site is really *in* scope. At the very least, it needs to be more secure than a SAQ-A requires.

It should be stressed that it is still early in the adoption process and the new requirement won’t be enforced until January 2015. There is still the possibility that the PCI SSC will tone down it’s approach over the course of the year and the final requirement could be significantly different to the current proposal. However, *assuming* it doesn’t change significantly there are going to be some clear winners and losers:

Winners:

i) The scanning companies. There are  literally millions of merchants that will now need quarterly scans and annual penetration tests

ii) Completely hosted platforms: thinking of hosting your own Magento instance on Heroku or using Shopify? We suspect that Shopify now becomes much more compelling due to the fact that the entire store is in their PCI compliant environment. That’s most likely still a SAQ-A for the merchant. Hosting your own instance of Magento (or any other shopping cart) on Heroku will require the SAQ-A-EP.

Losers:

i) Cloud billing and booking platforms that themselves are not PCI compliant and have relied on hosted payment pages from PSP’s/payment gateways to “offload” PCI compliance. If your competitor is fully PCI compliant they’re going to drive home the message that merchants using your platform need a SAQ-A-EP while merchants on their platform need the simple SAQ-A

ii) Per the above any SaaS service that is in itself not PCI compliant will be at a competitive disadvantage to those that are. Imagine Heroku vs raw AWS where the latter environment is already PCI compliant.

At the highest level, it appears that the PCI SCC is trying to close a loophole – they probably never envisioned so many merchants being able to use HPP’s and thus only needing a SAQ-A.  Clearly they want these merchants to have a much better understanding of what is required to ensure they have a secure site and as part of that are mandating checks by an outside third party on a regular basis. However, this is a significant change that affects a very wide audience. It’s hard to comprehend what will happen if/when this comes into contact with the real world and how many merchants will be adequately prepared for the heightened compliance requirements.

The next few months will be interesting. Like many, we’ll be waiting to hear more as the situation evolves.

 

Credit Card Vaulting: Direct Merchants vs Cloud Platforms

Modern payment gateways allow you to tokenize a card and stay outside of PCI compliance scope. Spreedly is unique in that we allow you to tokenize the card and then pass the underlying PAN to the payment gateway of your choice. The card never gets locked in or tokenized at any one particular gateway.

Why not just try and use a single global payment gateway? Great question. If you can, you should. For one, you’ll save on Spreedly’s fees. However, if you want to benefit from in-country transactions which are generally superior to cross border, then Spreedly can be a great choice.  There’s a couple of reasons why you might want to consider this approach:  decline rates tend to be lower within a country and processing costs are also much often lower. It also provides you with the additional benefit of being able to easily charge customers in their local currency and manage foreign exchange and remittance challenges separate from the payment gateway – this is an area where gateways tend to be feature-lite and fall outside their core area of expertise.

Spreedly customers such as Cabify initially collect and store a card from their customer and run that payment information against a Spanish payment gateway when that person orders a black car locally. But when that customer gets off the plane in Mexico and takes a car to their hotel, Spreedly gives Cabify the ability to then also run that same card against a Mexican payment gateway with no additional information or action required on the customer’s part.  The process is seamless and provides a superior customer experience, while also significantly lowering the processing cost incurred by Cabify by eliminating the need for a cross-border transaction (which tend to be riskier and incur higher decline rates).

From an App/developer perspective, Cabify has a single point of integration and one secure location for all their data. That doesn’t change whether they’re supporting 2 countries or 20.  From the business side, they can quickly add a new payment gateway when they enter a new region. If the gateway doesn’t perform as expected, or after being in the country for a while they realize there is a better option, they can easily switch. This dramatically reduces due diligence when selecting your payment gateway.

Cloud Billing/Booking platforms

Let’s say you come at the market from a slightly different angle. You have a mobile app that allows customers to quickly and easily book a taxi. So you want to securely store that card, get a token and stay out of PCI compliance scope. However, in your model you pass the final charge through to the participating taxi company. In this model, you have the payment gateway credentials for each taxi company set up in Spreedly. Now you’re passing the final charge against the payment gateway of the particular taxi they booked. Here again you want the retain that card and never have it locked in to a gateway. However, you also want to work with a range of payment gateways. Yaxi is a Spreedly customer doing exactly that right now, but we have many others doing something similar.

Another interesting mobile example is BusBud. They take the hard work out of booking a bus ticket by integrating with multiple bus companies behind the scenes. So they go out and buy the segments against the different payment gateways for their participating bus company partners.  Now, we have some really cool things planned for bus and other travel companies that will expose a booking API rather than being limited to solely transact against a payment gateway as is currently the case. But more on that soon – we’re still in beta.

Now you can see why we talk about creating a Stripe/Braintree type experience but *across* multiple payment gateways. You know who you are and now you know that we’re here for you – we love hearing about new user cases we haven’t even thought of yet!

 

 

 

 

 

Introducing the Spreedly Changelog

One of the many benefits of using a managed service is that new functionality, updates, and bug fixes are deployed without your involvement. The flipside is that it can appear, at times, to be a bit of a black box with changes going into production without your awareness. We understand your business relies on its ability to process payments and benefits from an awareness of changes to the Spreedly service. Starting today, any and all such changes will be documented in the new Spreedly Changelog.

The Spreedly Changelog documents functionality changes that are:

  • Externally-facing: noticeable to users of Spreedly
  • Generally available: available to all users of Spreedly and not in closed testing or limited release
  • Part of the Spreedly service: new and updated product features, not changes in documentation or marketing-related changes

We hope the Changelog gives you visibility into the changes we make on your behalf on an almost daily basis, and increases your confidence in our ability to maintain and operate a service on which your business relies.