Failed transactions are a part of life when accepting credit cards online, with insufficient funds and expired cards being two obvious examples of what can go wrong. However, often the reason for a failure is not clear and can be quite perplexing. Many merchant's accepting online payments know the frustration where after many months of successful renewals a recurring charge is suddenly declined for a customer who swears there are sufficient funds. Or there might be a specific country where failure rates seem higher - but are they? Or a potential customer may have a failed transaction on your site while telling you they just used their card ten minutes earlier successfully on another site.
Failed transactions are a serious issue. They result in lost sales and/or customer support contact, and that means they cost real money.
Merchants are often very geared toward squeezing 100 basis points out of their CC processing rates. Yet changing payment gateways to shave off 100 basis points only to see a 3% increase in failed transactions doesn't make economic sense.
What's the Problem?
The problem is data. Merchants don't have absolute data and they don't have relative data. You know (hopefully) what your decline rate is, but how does that compare to other merchants at your gateway? And how does that compare to a similar merchant at
gateway? Too often the answer for high declines from a gateway can be cryptic at best for a frustrated merchant. The payment gateways can be opaque due to the fact that many failed transactions relate to fraud/security filters, and they're afraid of giving away too much if they describe how they reach some of their declines. However, they can also be opaque because they just don't know, at least at the support/account management level.
globally. This gives us unique insight into performance within and across different payment gateways. It requires scale to be effective. We're starting to hit scale, at least with the largest gateways, where we can help. One of the most powerful things we can provide is context. We can work with you to better equip you when discussing these issues with a payment gateway. In addition, if after all your efforts your gateway isn't responsive then you're free to change without fear of data or API lock in.
A Use Case
We were recently approached by a customer who was frustrated. They felt "in their gut" that their failed transaction rates were increasing. The customer¬†also wasn't¬†getting helpful answers from their payment gateway. And, they were growing, which made it hard to tell if it was linear or accelerated decline rates. So we took a look at their data.
Here's what we saw from a quick first pass.
We started with Q1 of 2011 and did a quick YoY comparison.
So the trend was definitely moving in the wrong direction. Next we looked at the most recent quarters in general (based on customer feedback). That was a lot more revealing:
We learned two things. There was a big dramatic jump between Q2 and Q3. Yet it also trended down a little in Q4 and into Q1.
Next we dug in on Q3 first and broke it down by month:
It's no surprise the customer was super frustrated. We were also getting closer to finding the key date. We dug into August and saw that the mid-point of August was the real culprit:
Now, our customer could have captured this data on their own. Where we add value is in the context. We looked at all other customers working with that payment gateway across that same time frame:
What We Learned
Our conclusions were:
- There's nothing breaking/new between Spreedly and this payment gateway as other customers are not impacted (always important to rule out)
- The customer knows that they're now well outside of the norm for that gateway.
- The timeframe for the significant change is very well defined. The customer needs to understand if there's anything they've done to impact change (change price points, plan lengths, run any crazy specials)
- The gateway needs to understand if they did anything differently in that timeframe to also impact that customer.
We could continue to drill down and compare end points, average transaction size, net new vs recurring etc. Due to customer privacy concerns we can't share where we went from here for a resolution.
Our takeaway was we need to be more proactive (after all, our customer approached us). Which means we can (and have since):
- Effectively monitor our payment gateway partners like packets on a network for our customers.
- Catch issues before they become long running.
- Work with our customers and their payment gateways to do whatever is necessary to drive out "false positives".