It should be so simple: you're a customer who wants to purchase something so you whip out the credit card and buy it. I must have done this thousands of times, and it's easy! I've bought stuff with plastic credit cards, stuff with Apple Pay on my phone and watch and, like all of us, loads of stuff simply by entering credit card details into a website. A lot of that has been business expenses for which I've obtained a receipt and then claimed back, either in my joyful life of independence or in a decade and a half at one of the world's largest companies.
Don't get me wrong, credit cards have their faults too. I've had them defrauded many times now, but that's usually just a minor inconvenience. Getting one can be painful if you're young and have no credit record, but a debit card is much more easily obtainable and still gives you all the same purchasing power so long as you've got cash in the account. And, well, that's about it. Frankly, I find it increasingly weird when a credit card can't be used. I travel a lot to different corners of the world, and it's extraordinarily rare not to pay for pretty much everything with "plastic". Increasingly, that's the only possible way with it not just being the defacto payment standard in most countries I visit but increasingly being the only form of payment accepted by many stores. Not using a card is becoming increasingly antiquated; today, I stood behind a woman buying a carton of milk with a $20 note, and geez, it was slow compared to the 5 seconds it took me to buy a few bucks of potatoes with my watch. Which makes me all the more frustrated by what I'm about to write:
Five years ago, we started charging a few bucks to use the Have I Been Pwned (HIBP) API. It was primarily to stop abuse, and it worked beautifully! Turns out that once you have to stump up a credit card tied your IRL identity, you're a lot less inclined to do nasty things. Implementing this via Stripe was a breeze, and as the years progressed, that model gradually evolved. A few years later, we added higher rate limits, and with that came annual billing as well. The following year, we put a price on searches of the largest domains and coincidental to this blog post, that was about a year before the time of writing. This led to a lot of new subscriptions, which means now is when those that were taken out annually are starting to renew and subsequently, now is when the problems are really hitting.
Let's scroll back a bit and talk about "Neville". Neville works in the procurement department of a large organisation, and his job is to take that dead simple credit card purchase process and turn it into the most convoluted, laborious, and mind-numbingly stupid exercise possible. That all begins with wanting a quote for the product. Now, you might reasonably look at this request and think "Neville, why on earth do you want a quote when the price is already on the website?!" These services start at $3.95; does creating a quote that merely reproduces the publicly published price and puts Neville's company name on it actually achieve anything? No! Occasionally, Neville will just ask for an invoice, which again, just reproduces publicly available information in a PDF just for him. But that's "protocol", and Neville is a stickler for doing things by the book. Oh - and no credit cards. WTF Neville?! Yep, electronic funds transfer only and that'll be on 60 day terms in arrears too, thankyou very much. That's just Neville's way.
I often liken this to when I'd travel to Hong Kong for work. It was always a multi-day trip and inevitably, I'd need to eat. So, I'd find a nice noodle bar somewhere and order my fill, probably paying about the same amount as that $3.95 HIBP entry price. Now, imagine a Neville driving my noodle purchasing such that as I rocked up for lunch, ordered my noodles and was presented with the EFTPOS machine I said "No, I'm going to need a quote first". For noodles. And further, once I accept that quote, I'll need an invoice which I'll pay within 60 days (which really means somewhere between 59 and 60 days, because "Neville"), and I'll need your banking details too please, because we don't do credit cards. I never tried that, but I'm confident that if I did, I'd get a stern Cantonese version of GTFO. And rightly so.
But that's where we quite literally are with HIBP; the Nevilles of the world eschewing the most simple, universal form of payment in favour of, well, the exact opposite. Every organisation is different, of course, but these are the patterns that play out over and over again. The "we can't purchase anything by credit card" line in particular is pervasive, and in all seriousness, I do wonder: WTF do you do when you travel?! Surely there are people within your organisation that go far enough away from HQ to legitimately justify a meal somewhere, and clearly they're playing out the scenario described in the previous para. So, you have a way, it's just selective. But Neville persists, and we make it possible to do quotes and invoices for sufficiently sized subscriptions at the expense of our own time. Neville is now happy - almost.
"We can't pay by credit card". Over and over again, we get this line. Often it's not even that blunt, it's more akin to "can we have an invoice" which usually turns out to be code speak for "can we have an invoice and pay by EFT". Now, I don't particularly mind electronically transferring funds around account to account, but it's messy. We've got BSBs identifying the bank here in Australia but then it's typically SWIFT codes elsewhere. No problem, we can do that, but then we have the next problem: who just paid us? I mean, there's a sum of money that has appeared and it's identical to all the other sums because we're providing the same service to many different parties, so... who just paid? You can always reference an invoice number in the description of the payment, but that's up to the sender of the money and very frequently, that just doesn't happen. The sender's name doesn't necessarily make sense either, and even if it does, we're now burning time doing manual reconciliation. Further, it's not instantaneous like a credit card so not only are we waiting around for a payment before being able to do reconciliation and then turn on the service, the purchaser is also waiting around; they've just been notified a bunch of their staff are caught in the latest data breach that could have serious impact on the org and they need to... wait. And all of that doesn't matter anyway because we have another major problem: Stripe.
You know how earlier I said that Stripe was a breeze? Let me clarify that by saying that Stripe can be a breeze, and it can be an absolute nightmare. If you've implemented their service before and read the previous paragraph you may be thinking "why aren't you just using their bank transfer payments feature", and you click on that link and realise why:
No Australia ☹️ Which is a real shame because they have these cool virtual bank account numbers which take care of the reconciliation problem I mentioned earlier. I've prompted them directly on this over the years and the best solution I've had is to go and jump on Stripe Atlas which involves incorporating an entirely new company in the US:
I have absolutely no desire to have yet another corporate entity anywhere, let alone on the other side of the world. The current accounting burden I have each year is already a bit nuts, the last thing I want to do is make it even worse because Neville is being a stickler for an arbitrary internal protocol.
But there's another solution, one that opens up a whole new can of worms: resellers. I'm struggling a bit to even know where to start here, but imagine a digital product like an HIBP API key but instead of purchasing it direct from us, you take the time to go to someone else (the reseller) who purchases it on your behalf, adds a hefty markup and then charges you for the exact same thing you could have bought yourself with a lot less mucking around. Genius!
I blame Neville. It was inevitably a Neville in my previous place of work that demanded all purchases be routed through a single supplier. That meant that every time I found a great online service or product, I had to stop, think of Neville, and then contact the reseller of choice. That, of course, added overhead in terms of both time and the inevitable markup on the price of the product. I'm sure there's a reason why this makes sense in Neville's world. It probably has something to do with having fewer vendors the organisation deals with directly or delaying payment and doing it in bulk or something like "consolidated accounting"; who knows? The point is it's more time, more money and more pain. But they do solve one problem: the credit card situation.
We ended up acquiescing and allowing resellers to purchase on behalf of our customers primarily because the reseller is happy to pay with a card and then invoice the actual customer and do the whole EFT thing. That solves the problem where Neville has decreed that all purchases must go through the reseller because "reasons". What we don't do is entertain the request for a "reseller discount", a request we receive on a pretty frequent basis. It's nonsensical: instead of the end customer just going to the website, chucking in their Visa and being done with the whole thing in a couple of minutes without any assistance from us, instead, we have to do the legwork of interfacing back and forth with the reseller to create the appropriate documents, and after spending our precious time doing that, they also want a discount! Not gonna happen. But given the reseller is in the money-making business, they whack a hefty markup on the top to the detriment of the customer who decided to use them. It's nuts.
This brings me to today's problem and the (other) problem with Stripe. As annual renewals approach, resellers are reaching out wanting invoices for their customers' subscriptions. No problem (this is my naive brain response), both those constructs exist in Stripe, and we often use them for new subscriptions. However, there's a massive blind spot in Stripe's implementation: an invoice can only be raised when a subscription starts, creating a huge problem when resellers reach out three months in advance. I blew the better part of all of yesterday trying to work out how to do this and concluded the following:
- You can only start a subscription in the future by creating a subscription schedule, but the invoice won't be generated until the subscription actually starts, so it doesn't solve our problem.
- You can't buffer out the start of the subscription with a free trial because the invoice still won't be raised until the paid portion of the subscription starts.
- You can create a quote with a subscription start date in the future, but you can't raise the invoice until the subscription actually starts.
Charlotte went backwards and forwards with Stripe support on this. Here's their final position:
There is no option to make an advance payment for a subscription or renewal yet. I've passed it on to our product team. Unfortunately, we can't guarantee that this feature will be implemented at the moment, but we’re rapidly evolving our product suites, so be sure to stay close to hearing about new products and features as we announce them.
To summarise everything you've read thus far, because Neville won't approve credit card purchases and Stripe won't allow EFT payments, we're stuck with resellers who now want renewal invoices, which we can't raise because Stripe won't let you do that in advance of a subscription starting. Look, it's the finance industry, so there are lots of regulatory hurdles that I can see making things like EFT payments to virtual bank account numbers in Australia painful. I think Stripe's implementation is beautiful in so many ways, and I have massive respect for their technical implementation; the API docs are top notch, their CLI is really cool, the webhooks on events work beautifully, and their portal is lovely to use. Kudos all round to the Stripe devs. But why something as simple as raising an invoice in advance of the service starting isn't possible just doesn't make sense for a digital product like so many of the ones we buy online. I mean, what's the answer: wait until the subscription cycle renews, at which point the service is discontinued until the newly issued invoice is paid? That's where we're headed because so many orgs (including resellers) simply won't pay until there's an invoice. (In case you're wondering, they often use credit cards with short-lived expiry so they can't just be automatically charged on renewal.)
By writing this, I know I will get a flood of either "don't use Stripe" responses or "support multiple payment providers" suggestions. Both of these are a nightmare as Stripe is so closely integrated into our service. If someone wants a historical invoice or receipt, we bounce them off to the Stripe portal. When a Stripe payment is successful, that's the event that calls a webhook on HIBP and enables (or extends) the subscription. And yes, we could build a heap of additional code to support other providers, but that's masses of overhead just because Neville doesn't like credit cards.
Curious, I ran the numbers on resellers and came up with 0.6% of total current subscriptions. In other words, if you're in an org that insists on EFT and / or a reseller, there are 160 other people just like you who are working in a Neville-free environment. I feel your pain as I've walked in your shoes, but I also know that credit cards are an arbitrary barrier a sufficiently motivated organisation can overcome.
If you've read this and have suggestions, please chime in via the comments below.