Empowering Developers To Build a Great Payment Experience

Monika Ocieczek at UXDX Community: Nordics. Video: https://www.youtube.com/watch?v=iUqwgt_O4mw

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

The problem Primer solves

[00:00:00] Hi, my name is Monika and I'm heading up product design at Primer. We're just over two years old and I've been with the team since May 2020. Primer is an automation platform for payments and commerce, and the developer experience is at the center of all of this. In this presentation I'll be talking about how we think about DX, and tell you the story about how the integration of our checkout has changed over the last two years. But first, a short intro to Primer and the problem that Primer solves.

[00:00:32] The payment space has exploded with innovation. There are new PSPs, local payment methods, fraud prevention tools, loyalty rewards, buy now pay later, open banking and more, and merchants want all of it, so they keep building new integrations. They want more than that. They want to enhance their payment experience, improve authorization rates, reduce cost, improve conversion at the checkout, mitigate fraud and more.

[00:01:03] But this is what they end up with: expensive payment stacks and sophisticated strategies lead to mountains of spaghetti code. Our merchants are on a mission to deliver the best possible user experience, not to understand payments, but now they have to deal with tons of third-party integrations.

[00:01:23] And then there's the checkout. If you've paid online you know how often the checkout experience is bad and how often it fails. Building a good checkout is really hard. You need to consider PCI compliance, expired cards, errors, accessibility and localization, just to mention a few things. Checkout flows are complex, and you have different UX on native apps and on the web. Technical fragmentation adds to this complexity, and user experience and conversion suffer. This is what you need to actually build a Shopify checkout. It's a lot.

[00:02:04] Primer is a technical infrastructure, an automation platform for payments and commerce, allowing merchants to expand their payment stack with clicks instead of code, and define complex logic in a simple drag-and-drop workflow UI. Just add your apps on the dashboard and configure workflows.

[00:02:22] And then there's Universal Checkout. Our checkout is an SDK for web and mobile. This is what you need to integrate Primer's Universal Checkout. It's a very simple DX. It takes only a few lines of code to initialize and render Universal Checkout, and the checkout goes from being an engineering obstacle to a feature that actually enhances the user experience.

[00:02:46] Universal Checkout works perfectly regardless of where your payments are being processed, which payment methods you use, where your customers are located, if your store is on the web or in a native app. It's PCI compliant, it works out of the box and is fully in context of your store. It's configured without code in a simple UI, and dynamically synced with workflows, allowing you to define the checkout flow and the logic in a UI instead of in code. So you can see how the checkout is optimized from a developer perspective and merchant perspective, as well as a consumer perspective.

How we think about developer experience

[00:03:24] This is how we think about developer experience. It should take no more than five minutes to integrate our checkout. You only need to learn payments once. Then it's zero maintenance or additional integrations, because the rest is configured and managed on the dashboard.

[00:03:42] Primer started two years ago as a unified payments API with a unified payment lifecycle, allowing engineers to only learn payments once, only ever build one payment integration. But our customers would build their own checkout, and we know how hard that can be.

The first version of Universal Checkout

[00:04:01] During my first week, Paul, one of the founders, messaged me and said, Mon, a merchant is asking for a feature. And they wanted a checkout. They were using Braintree and they were happy with their checkout, but they weren't happy with the fact that they were limited to Braintree. They wanted to expand their stack, use multiple PSPs and add new payment methods. They needed an agnostic universal checkout. And what made it interesting was that they were asking for a ready-made checkout, a drop-in UI, something with minimal engineering work.

[00:04:35] We designed it. This is the very first, incredibly simple version of what we call Universal Checkout. We moved fast so we had to keep it simple, and immediately realized some design challenges. We didn't follow a straight design process because there was no time. As an early stage startup you need to move fast. And there's no user persona. The checkout has to be designed and optimized for everyone.

[00:05:04] Primer's merchants vary in size, market, category, and there are actually a lot of other factors to consider beyond user needs. We need to care about the merchant who's making the decision to use Primer, as well as the developer who's integrating the checkout, in addition to the consumer who will be using it. There are technical and legal constraints and dependencies. Imagine all the different payment methods and 3D Secure. But it has to work. We couldn't ship a half-baked checkout MVP, because the checkout is just too important for conversion. So we found ourselves designing for the least terrible experience rather than the ideal experience.

[00:05:45] Here it is: Universal Checkout in the wild, as one of our first merchants implemented it. It was quite a disappointment. We realized not every merchant will be good at styling, and these guys actually hacked our ready-made UI to do this. And here's another checkout fail: don't forget to define the max width. We had some challenges here, because we really wanted our checkout to look great when implemented, but we didn't have control. Merchants have and should have full control over their checkout.

The checkout's growing complexity

[00:06:20] As more and more merchants were integrating our checkout, we got a lot of feedback. Merchants wanted a working checkout out of the box, but they also wanted full control over styling. Some of them asked us for code snippets because they didn't want to deal with styling the checkout to fit their brand and their website. We helped, but that doesn't scale.

[00:06:43] We added more styling options, but there were more requests, and we kept adding new features like discount codes, tax breakdown, surcharging. And there was a lot more merchants wanted to do with their checkout. The checkout's growing complexity. So we needed to simplify this into something manageable, easy to understand.

[00:07:04] We introduced checkout modules. Those are additional features that enhance the checkout experience. They can be added without additional integration work. These can be third parties, like charity donations, or it could be Primer native features, like capturing the user's email address. Instead of adding a feature as a new feature, we treat all of them as checkout modules that can be easily added on the dashboard without additional integration work.

[00:07:35] Meanwhile, we kept adding new payment methods. Some of them brought new flows and behaviors, which added even more complexity on the checkout integration. And the checkout's growing complexity: we went from this very simple integration flow to something very complex, and our integration was no longer so simple. There's a lot of requests and responses to keep track of, loads of complex integration work, and the checkout SDK only does a small job here.

[00:08:08] The problem with the developer experience was that there was a dependency between front end and back end, so it was only five minutes in theory. In reality, front-end and back-end teams are not perfectly aligned and in sync. Sure, there was no more maintenance or additional engineering work when adding new payment methods or modules, but there was a lot to implement in the first place, a lot of concepts to learn and keep track of. We heard this feedback more and more often from developers integrating with Primer as the complexity grew over time.

You don't have to learn payments at all

[00:08:43] We needed to simplify this. Back to the drawing board and back to our core values. We went from "you only need to learn payments once" to "you don't have to learn payments at all, just add this code", because no one really wants to learn payments. Hotjar is a good example. You don't need to learn analytics to install and use it. Installation is easy and the rest is done on the dashboard.

[00:09:12] We went from this complexity to something a lot simpler. Our new checkout SDK requires no additional back-end work in order to process payments. No more back and forth. We've created a separation of concerns between back-end and front-end devs, and introduced enhanced checkout customization on the dashboard in our no-code checkout builder. Now all you need to do is to generate a client token, initialize Universal Checkout, and listen to webhooks in order to show a success screen. This is really all you need to accept and process payments, and it works basically the same way on native mobile as it does on web.

[00:09:52] We managed to dramatically reduce the integration and the technical complexity, because the best DX is as little DX as possible. And we've also simplified our code a great deal.

[00:10:06] How do we do all of these new capabilities without making it more complex for the developers? The way we think about it is we try to create the minimum number of concepts that scale. Payment methods is one, and checkout modules is another one. And we build no-code tools whenever possible. The checkout builder is a simple UI for managing payment methods, checkout modules and conditions. You might want to present PayPal to customers in certain countries, and only present buy now pay later options for certain amounts. You might want to define the order of your payment methods, and the same goes for checkout modules. Now anyone can configure and manage the checkout without writing code.

Headless checkout, one click and crypto

[00:10:55] But there's more. Over time we got more feedback from our customers. They were okay with the styling and controls, but they wanted even more flexibility. Some of them had A/B tested their checkout and wanted that exact thing. They wanted to build their own checkout, own all of the styling and layout, but with the smartness of the Primer platform.

[00:11:19] We introduced headless Universal Checkout. Compared to other headless checkouts out there, Primer's Universal Checkout still enjoys the smartness of the Primer platform, and we do all the work, but your designers and developers get to define the UI completely. Now if you don't want to use our ready-made UI with styling options, you can use headless Universal Checkout and define the UI and layout. You decide what's best using your data, based on your preferences, and you can conduct your experiments and A/B testing to optimize the experience.

[00:11:55] There's more cool stuff. We're now introducing a one-click checkout, aiming to improve conversion by storing customer details in a shared vault across the entire network of all the merchants that use Primer. So if a customer has registered their details on any merchant store, they can sign in and pay faster next time, resulting in fewer cart abandonments and a faster, less painful payment experience. And of course there's no additional integration work needed to enable one-click checkout.

[00:12:25] For all Web3 lovers out there, recently we announced that Universal Checkout will support crypto payments. Again, no integration work is needed. When we add new types of payment methods and features, you just activate them on the dashboard.

The checkout as a framework, and the docs

[00:12:41] As you can see, the checkout has become more of a framework than a fixed product for a specific use case and customer. Going back to my point in the very beginning about how hard it is to design a checkout that will be used by everyone: it's actually impossible. We want to keep the integration as simple as possible while allowing all the flexibility, sophistication and features that a merchant might want. That's why we need to think of it as a framework.

[00:13:08] Universal Checkout has an incredibly simple DX and comes ready made out of the box with extensive styling options, but you can also use the headless version if you want to control the UI completely, and you can easily enable one-click checkout. Modules enhance the checkout with additional features, and payment methods can be configured to optimize the checkout experience based on the market, product type or more.

[00:13:33] None of this would have much value without good docs. You can have a very simple integration, but if your docs are not easy to understand, if your integration is not well documented, the DX is going to be painful. At Primer, docs are a first-class product area owned by a dedicated team, the developer success team. We put a great deal of effort into simplifying complexity, not just in the integration itself but also in how we explain it in the docs: minimal number of concepts to learn, helping visuals, easy to understand descriptions and always up-to-date content.

[00:14:13] And that basically wraps it up. Our north star is to become the biggest enabler for commerce in the world, with as little DX as possible.