I know we’ve moved on since WWDC, but I wanted to keep talking about taking payments for your software outside the App Store, and how I think many people have an unfair view of making payments through anyone not named Apple as some sort of security nightmare.

A few weeks ago I wrote about some of the business and technical reasons a merchant may want to handle their own payments and not let Apple do it for them. Today I wanted to dig into what the experience is like for merchants when they decide to do their own payment processing in 2020.

Offloading the Risk

Payment processing is a tricky thing and it’s very technically complex. However, that’s why companies like NMI, Stripe, PayPal, and the rest exist: we let merchants focus on running their business as we take on most of the complexity and risk of processing payments. Major retailers may work directly with a payment platform (First Data, TSYS, etc.) to process payments, but the vast majority will go through a “payment gateway” that simplifies the process and reduces the risk for the merchant. For example, NMI (where I work) integrates to over 100 payment platforms, and we have a unified API and UI for working with each one. You don’t need to know anything about TSYS’s spec to run payments through them, you just need to know ours. If you want to switch to First Data tomorrow, that’s fine, you don’t need to change your workflow.

Risk is another factor, and it’s a big driver of innovation in the payments space right now. Merchants want to make it as easy as possible for customers to pay them, and in 2020 basically no merchant ever wants to have your unencrypted card data touch their environment. Thankfully, nowadays there are plenty of “SAQ-A compliant” solutions out there that allow merchants to deliver their customers good, reliable checkout experiences, in ways that make it so that the merchant never even knows what your card number or CVV even are.

How Do You Get This Card Info Securely?

There are tools out there like Collect.js and Stripe Elements that let merchants insert text fields on their website that look like they’re part of the merchant’s site, can be tabbed through as if they were on the merchant’s site, but in fact they are very much not on the merchant’s site.

For example, here’s a test page I have set up today that uses my company’s Collect.js solution.

There’s no way for you to tell from the screenshot, but the ccnumber, ccexp, and cvv fields on this page are all iframes that are sitting inline on this page to look like the rest of the form. The point of these is that due to the way iframes work across domains, the merchant’s website has zero access to what’s going on in those fields. The tool can send callbacks to the merchant site to tell them that the field is filled out and is valid or invalid, but it will never make it so the merchant can see the card data. This gives merchants the ability to completely control the user flow through their onboarding process, all while offloading the risk of handling the card data themselves.

Another option is to do a full redirect to a hosted payment page managed by your payment provider. You likely know what these look like, as you’ve likely visited a site selling through one of these options yourself. Tapbots uses Stripe for selling Tweetbot for Mac licenses, but there are other options from NMI, PayPal, Amazon, Braintree, etc. These options take control away from the merchant, but they also simplify the integration since they are offloading the UI, UX, and payments API work to the platform. not to mention the customer may see the name of a company they know/trust in the URL and be more comfortable entering their payment details.

After the Purchase

But it's after the initial payment that things get really nice for the merchant. Let's say I have a Mac app someone bought a few minutes ago, they made a mistake, and they contacted me to get a refund. This is what I would do in my UI to issue a refund to them if I was handling the payment myself:

If I was selling through the App Store then I would have to tell the user to ask Apple for a refund and hope that Apple allows it. I'm just not able to take care of my customer as quickly as I could if I controlled the payments more directly.

And this goes for everything after the intial purchase as well. I get dedicated UIs and APIs for accessing my customer list, transaction history, recurring summaries, and more. I can use webhooks to get real-time alerts when things happen on my account, and I can control how my customers in my payment gateway sync up with my list of customers I maintain in a CRM or something like that. You get some of this in the App Store, sure, but it's not nearly as much and is far more limited in scope.

Takeaway

You may like this as a customer since it makes it harder for merchants to reach out to you with promotions, but the downsides are that it can be harder for the merchant to run their business and stay in business in the first place. I'm all for user privacy as well, but we have to consider the challenges things like the App Store present to merchants who are trying to do the right thing as well.

My point in writing these last couple articles is to point out that while there are definite benefits to merchants and customers with selling through the App Store, there are also costs to that system, and I wanted to share a peek into what merchants have access to these days.