SCA experiences of a small business
Sometimes, the work that goes into fman is not visible to fman's users at all. August has been a good example of this.
In Europe, we have a new payment regulation coming up called "Strong Customer Authentication". It's a scheme devised by EU bureaucrats to combat online fraud. It requires companies that take online payments to build additional authentication into their checkout process. Essentially, where you may have previously been able to just enter your credit card details, you may now also be required to authorize the payment in an app on your phone, or receive and provide an SMS TAN code.
After the EU data protection directive (GDPR) from last year, this is another case where I, as a small business owner, have to invest huge efforts, for benefits I do not perceive. Data protection and safer online payments sound good in theory; But in practice I have never had any problems, in 15 years of being online, with either of these topics. Like the forced and abundant warnings "this site uses cookies" that EU visitors to web sites get, I only see added complexity - and in my case very real financial cost to small businesses. But I guess after making me spend a week on GDPR issues last year, the EU has no qualms about making me spend a week on payment flows this year.
fman's web site uses Stripe and PayPal to process online payments. Fortunately, no work seems to be required to make PayPal's payment flows SCA-compatible. Unfortunately, for Stripe it's a different story.
Stripe offers a library called Checkout for letting you open a popup where customers can enter their credit card details. fman's web site uses the version of Checkout that was current at the time of initial implementation. Unfortunately, this version of Checkout is not SCA-compatible. Stripe essentially require me to rewrite all of fman's payment flows. While I'm generally a big fan of Stripe, I feel let down by this. I think they could have made it easier.
Because rewriting fman's Stripe integration from scratch did not seem like a pleasant task, I looked at alternatives. Fastspring seemed like a good candidate. Whereas with Stripe you need to handle everything from taxes to handling subscription renewals, cancellations, etc. yourself, Fastspring acts as a reseller that simply does all these things for you. Unfortunately, after a lot of time spent learning about Fastspring's (generally very powerful) APIs, it turned out that it does not support fman's particular payment model. (See fman's purchase page for details.)
So I dug my heels in and rewrote fman's Stripe-based payment flow. It does exactly the same thing as before. Just now, it's "SCA-ready".
I do also want to report that I encountered a hurdle in doing this, and was actually put in touch with Stripe's product manager for Checkout, who then saw to it that they implemented a change I needed. It only took them two weeks. That is pretty cool about working with such a dynamic company.
Still, for future projects, if at all possible I would start out with a reseller such as Payhip or Fastspring. It's just so much easier when you don't have to worry about issuing invoices, charging appropriate taxes, PayPal's 99 problems, or managing subscriptions.
I wonder how I'll be spending my EU-imposed "holiday" week next year ;-)