Mastering the Art and Science of Payment Design

Raymon Sutedjo-The at UXDX Community: Payment Design & AI-Based UX Optimization. Video: https://youtu.be/KLsFDCp9lu4

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.

Introduction and the basics of payments

[00:00:00] Hi all. Good morning, good afternoon and good evening, depending on where you are. My name is Raymon, and it is a pleasure to be here at the UXDX Community event. I'm so excited to give this talk today and share what I've learned about designing payments with all of you in the audience. Our agenda today is pretty straightforward. I'll start with a basic intro and the basics of payments, and then go into the meat and potatoes of this talk, which is designing payment products. I'll also talk about some future ideas before we wrap up. My hope is that after this talk you'll understand some basic key tenets when it comes to designing payments, and feel empowered to do so successfully.

[00:00:43] Like I said, my name is Raymon, and I am a design leader with years of industry experience at consumer and enterprise companies such as Medium, Salesforce and Accenture. I am currently at Marqeta, where I lead a team that builds products to enable and elevate modern money movement. Just a small disclaimer before we begin: the thoughts that I'm sharing here belong to me and myself only. I am not representing Marqeta or other companies that I have been a part of.

[00:01:15] So let's talk about payments. Payments as they exist today look pretty different from what they were in the past. We've gone from exchanging literal goods in a barter system, to physical cash, and now to the zeros and ones of digital payments. With each evolution, the ease and speed of payments continue to increase. Quick question: who of you on this call has made a purchase, or sent or received money digitally? Hands up, leave a comment. I can't see all of you, but I would imagine that most, if not all, of you have done so, especially since this is 2024. Digital payments are everywhere.

[00:02:01] Digital payments look so simple on the surface. Maybe you go to a shop, you tap your card, you wait a few seconds, boom, you're done. But when you look under the hood, there's such a huge amount of complexity. This is what it might look like behind the scenes. Let's say that you're going to a coffee shop and you're using your card to pay for a cup of coffee. You tap your card against the POS terminal, which then passes the info to the merchant bank and then to the card network, like Mastercard or Visa. The network then validates it and passes the information over to the cardholder bank, which approves it and sends it all the way back to the network, to the merchant bank, to the POS terminal, which then displays the authorized message. And now the transaction is complete.

[00:02:58] When you think about payments, it's really not just about buying things at a store. You can think of money movement more generally. For example, you want to send money to a friend to pay for your part of dinner, maybe send money to a family member who lives abroad, or pay out vendors or employee salaries, or get paid as a creator, and so on. A lot of you on this call are probably designers, and you might be curious, or maybe a little bit afraid, of what it means to design in this space. There are definitely some unique considerations when it comes to payments specifically, but the good news is that a lot of basic design principles still apply. So let's dive in.

Know your users, their use cases and the ecosystem

[00:03:47] When we think about transactions, they are so common that maybe we don't really think about them all that much. But if you think about the data that is contained in each transaction, it's truly rich in information: who are the parties involved, how much was it, when was it made, and so on. Here's an example of a purchase receipt, which displays data like the store address and contact info, the transaction date and time, the detail of the merchandise itself, the transaction amount and a breakdown, the payment method and authorization, and so on. But this transaction also contains data that is not shown, like the cardholder address, fraud rating [?], merchant category code, transaction type and so on.

[00:04:47] My point here is that while transaction data is rich, you still have to remember that transactions exist in many different contexts. For example, buying goods from a shop would be different from sending money to a friend or making loan payments. In each of those scenarios the user goals are a little bit different, so you should think about ways to support them accordingly. Don't show everything all at once in all scenarios. This is also applicable if you're dealing with commercial payments. For example, if you're paying a vendor for software licenses or goods or whatever it might be, in this case having information around things like approvers or department or invoice number would be useful.

[00:05:40] And last but not least, be mindful of nuances when it comes to the payments ecosystem. In the US, for example, credit cards are a pretty common way to pay, but they are also more expensive for the merchant as compared to, for example, Europe. Or in some countries, paying cash on delivery is still a common payment method as well. So think about how these differences would influence your design and product decisions. You have to keep in mind that you are always, always, always designing products and features in the context of an existing payments ecosystem, and never in a vacuum.

[00:06:22] In a nutshell, you've got to know your users and their use cases. Think about their goals and what would be useful in those contexts, and don't forget about the payments ecosystem. As a designer, you have to be diligent about this. What data or what research is available to support your hypothesis? How would you collaborate with your stakeholders to answer these questions? And so on.

Clarity over speed

[00:06:48] In tech you often hear the phrase "move fast and break things," but this is not necessarily the best approach when you're dealing with payments, because we're playing with a different set of rules. People are so sensitive about sending and receiving money, and mistakes can be costly, literally. It might sound counterintuitive, but a frictionless experience can be harmful in the context of payments. Preventing human error by adding a little bit of friction is easier than trying to undo transactions.

[00:07:24] Quick story time. A couple of years ago, in 2021, a Citibank employee accidentally sent the full amount of a loan, which was $900 million, instead of just the interest, which was $7.8 million. The software, as you can see here, isn't exactly clear. The user was supposed to check multiple checkboxes here, not just one, to override the default settings. And this still went through despite multiple layers of approval as part of the process.

[00:08:00] The moral of the story here is that clarity is critical. You can't depend on processes alone to prevent catastrophic human errors. For example, how would you make this workflow clearer? Maybe you add a summary screen before executing the transaction, maybe you put in a delay, or whatever it might be. When it comes to payments, really, speed is secondary. Clarity is more important, and adding friction in the product experience is actually preferable.

Trust: transparency, accessibility and privacy

[00:08:35] To build on that, clarity also means being transparent with users and building trust with them, whether it's things like fees, the conversion rate, or when the money will arrive, and so on. You might be tempted to use dark patterns to hide some of these. But when you think about dark patterns, they might be beneficial to the business in the short term, but they erode trust in the product in the long term.

[00:09:04] Interestingly, there's also evidence that being transparent might actually be beneficial to the business. In the US, unbanked, lower-income consumers often use check-cashing places to liquidate their money in spite of the high fees. You can see here the list of fees that are associated with the check amount. But the transparency here means that the consumer knows exactly what they're getting and how much they're getting in the end. Whereas at banks, fees like the monthly account fee or overdraft fees and so on are less visible to the consumer, and they can really wreak havoc on people's finances, especially if you live paycheck to paycheck.

[00:10:00] We've been talking about digital payments and how speedy and convenient they are, but in addition there's also some opportunity around access and equity. Cash in particular can be a little bit inaccessible to people with visual impairments, those who are blind or have really poor vision, and making it accessible would mean major changes in our current infrastructure. Now, I can't speak on all currencies, but US dollars are definitely one of those, because all the bills are the same size, whether you're looking at a $1 bill or a $100 bill.

[00:10:37] So when you're building products or features in digital payments, accessibility should be part and parcel of your process. Making it accessible as you're designing and building is much, much easier than trying to fix it after the fact. Now, this talk isn't focused on accessibility specifically, but I'd be remiss if I didn't mention that accessible products also benefit every person, every user that uses your product, not just those who have disabilities.

[00:11:12] Earlier I mentioned how transaction data is really rich in information, and with the explosion of digital payments, different products are also experimenting with the social aspects of transactions. But this can present privacy risks if you're not careful. So if you're building digital payment products or features, treat your user data with the utmost care. Another advantage of digital payments is how easy it is to share your financial information across accounts. With a click of a button, you can connect your mortgage payment, for example, to your bank account. But it also doesn't mean that everything should be shared everywhere by default. Doing so might increase privacy and security risks, not just for you but also for all the parties involved. So we should empower users to have control over their financial data and access.

[00:12:12] Needless to say, trust is a key tenet when it comes to payments, so we have to build products that are transparent, accessible and respectful of user privacy.

Deal with fraud head-on

[00:12:26] The last point, about security and privacy, is especially important when we consider fraud. In the US alone, there were about 2.6 million fraud reports in 2023, and this resulted in about a $10 billion loss. This is a significant amount of money, and I can only imagine the numbers being even bigger when we go outside of the US. The unfortunate reality is that fraud is inevitable when it comes to payments. Digital channels have made it so much easier for bad actors to scam people out of their money, and now with AI, things have become even more sophisticated.

[00:13:12] In one extreme example, scammers were using deepfake videos in a live call, mind you, not pre-recorded footage, in a live call, which is wild, to trick an employee into paying out $25 million. Those AI-generated videos that you've seen on social media or wherever aren't just silly tricks. Bad actors are actively using those new developments and new technologies in AI for malicious purposes.

[00:13:44] But on the flip side, we're also seeing a rise in AI-powered detection and mitigation methods. In essence, the system first establishes a baseline of what normal looks like, then monitors the data continuously and flags deviations as they occur. In the long term, it also continuously adjusts its logic and parameters as new data comes in. There's definitely some overlap here between this point about AI and the previous talk. In the current day and age, you have to deal with AI and think about how that might impact your designs and products.

[00:14:30] And of course, I think some of you, if not most of you, have dealt with fraud as the victim, or been on the receiving end of fraud, which is so stressful. Who wants to deal with that? So it's also essential for you as designers and builders of products to make fraud prevention and mitigation a part of your product. To mitigate those negative impacts, you'd want to alert the user in real time and automate protection to stop the bleeding first. Then you'd want to provide a shortcut to reverse it if it's a false positive, and also create a pathway to recover if it is indeed fraudulent activity.

[00:15:17] When it comes to fraud, you have to deal with it head-on. There are no ifs, ands or buts. Bad actors are always lurking in the background, and they will pounce at every opportunity that comes up. You can either be caught flat-footed or be prepared to deal with it.

Compliance: don't mess with the law

[00:15:37] Another unique thing about finance is how regulated it is. You will be dealing with multiple parties in the mix, like banks and networks, Mastercard, Visa, UnionPay and so on, who each have their own compliance requirements. Not to mention that different types of programs have different requirements. A debit program, for example, would be governed and bound by a different set of rules from a credit program. These requirements can also vary. Some might be pretty high-level, generic guidance, while others can be very, very, very specific, like this example of card art display from Mastercard.

[00:16:23] Of course, I'm not a lawyer, you're not a lawyer, and that's fine. You don't need to know every single thing off the top of your head, but you are still responsible for your designs and your decisions. Do your homework. Review your designs with the legal and compliance experts at your company. In a nutshell: don't mess with the law, and don't assume things.

The future: fast, connected and smart

[00:16:47] So far we've been talking about payments in a present context, but of course payments continue to evolve, and exciting developments are happening all the time. When I think about the future of payments, these come to mind. The future is fast, because of real-time payments; connected, thanks to open banking; and smart, made possible by programmable payments. Payments is a constantly moving field, and as designers and builders you should at least be aware of these developments so that you can continue to build and evolve your products and services.

[00:17:30] Real-time payments are the new, quote-unquote, hot thing in payments, because they enable money movements to be completed in seconds, not the hours or days of older methods like ACH or wire transfers. This has a huge impact on liquidity, and also potentially on financial inclusion. But on the other hand, there's also increased potential for fraud due to the instant and irreversible nature of real-time payments. And speaking of the US, the adoption of real-time payments in the US has been a little bit slow compared to other geographies, like India, for example, with UPI. So right now in the US, at least, coverage is a little bit patchy at best.

[00:18:15] I've touched on this a little bit earlier, but open banking has also become increasingly popular. Today it's never been easier to share your data across companies, with services like Plaid, for example. For consumers like you and me, it means that we are more in control of our financial data. And for companies, this could also mean lower barriers to building and offering financial products, even if it's not a core part of their offering, and this is what embedded finance is all about. But it's not without its challenges. Again, when you share data with multiple parties, they will have varying security levels, and your data will only be as secure as the weakest link. Additionally, considering that there is still a large segment of the population that is unbanked, open banking might disproportionately benefit those that are more well-off and tech-savvy.

[00:19:21] Last but not least, programmable payments, which isn't really a new concept per se. For example, think about your Netflix subscription, where you're automatically paying a certain amount at a regular interval, like monthly or annually, for access to a service. But this could go way, way, way further. The conditions set for programmable payments can be pretty sophisticated and complex, especially in commercial use cases. For example: send payment if the shipment has arrived at the East Coast warehouse and two supervisors have signed off on inspections. So we're combining things like geo, time, role and so on and so forth.

[00:20:15] When you think about smart payments, or programmable payments, automated execution like this would reduce operational overheads and human errors, while at the same time increasing safety and transparency. There is also the potential for more dynamic pricing models beyond your basic usage tracking. Of course, on the flip side, it could be less flexible, especially during abnormal circumstances like a natural disaster or a pandemic, which we're all pretty familiar with. And last but not least, there might also be some privacy and ethics questions due to increased surveillance.

Wrap-up

[00:21:00] To wrap up, I'd like to remind you of the key tenets that we discussed earlier when it comes to designing payments. First, you've got to know your users and their use cases. You want to prioritize clarity over speed. Continue to build and maintain trust. Deal with fraud head-on. And last but not least, be compliant with laws and regulations. Payments, whether you realize it or not, are so central to our lives. Everyone needs to pay and get paid, and payments are how we make it happen.

[00:21:41] And that is all. Thank you so much for your time and attention today, and I hope the talk has been insightful for you. I've included here a QR code link where you can get a copy of the talk and give me some feedback, and I would also love to connect with all of you on LinkedIn as well. Thanks again, and I think we can open up the floor to questions now.

Q&A

[00:22:04] Host: Excellent, thank you very much, Raymon. That was a really nice deep dive into some of the complexities that are hidden behind the scenes in payments. I'll jump in with the first one, because this is actually something that happened to me. Like you said, you need to introduce friction in payments because you don't want people to make mistakes. But when I'm doing my payments, I almost have a muscle memory of "I have to do these three different taps in order to make a payment go through." And then I accidentally made a bad payment, because I wasn't using it as a way to validate my payment. I just knew that to do the payment, I had to hit these three different taps. So is there something else that can be done to try to avoid that, or am I just the silly end user? That muscle memory that people might build with the friction that you introduce.

[00:22:59] Raymon: I think there are a couple of things there. For example, maybe there's some sort of learning that we can do in the back end. If we see, "Hey, you're sending a lot of money frequently, and maybe more than usual. Is everything okay?" So trying to detect patterns, or interaction patterns, and maybe present additional friction, or a guardrail, in some cases. And also, in some cases, again depending on what you're trying to do: if it's for a bigger amount, maybe we give you a certain warning. Maybe if it's a new person that you're sending money to, we present an additional speed bump. So I think understanding what some of the use cases are would be helpful in terms of introducing potentially additional friction points.

[00:24:01] I think Venmo does this well, in the example that I had with the pausing. I don't know if I can zoom in or not, but it says here, "You cannot pay or charge the same person the same amount within 10 minutes." And also with Venmo, if you're sending a payment to somebody new that you have never sent a payment to before, it'll ask you for additional info, like the last four digits of their phone number. And those kinds of verification don't show up all the time; they only show up in certain cases. So I think understanding the, whatchamacallit, intricacies of some of these use cases would be helpful.

[00:24:49] Host: Brilliant. There's a good example, I can't remember which app it is, but when you want to delete something, it pops up a box and you have to type "delete" instead of clicking a button. That's just an extra step, because then you know very clearly that you're deleting something.

[00:25:05] Raymon: Yeah, I think that might be GitHub or something, because I remember having to do that when I was trying to delete a repository.

[00:25:14] Host: The other thing, with fraud: you were saying to try to always be vigilant, and I was thinking about fraud. How do you protect against something like an AI video chat with your boss, where they're telling you to do something? How do you protect against something like that? That's a tough one, isn't it?

[00:25:37] Raymon: Yeah. I think with something like that, there's something that you can do in the product itself, but also something that has to do with the system overall, the organizational system, dealing with humans. For example: "Hey, if you're sending this much money, or over a certain amount, you need additional approvals from your supervisor," or whatever it might be. It's not a perfect system by any means. But when it comes to AI-powered stuff, it's tricky, and it's still new. Cases like the one I shared aren't exactly happening every single day, all the time. Those cases are super targeted. They know that they're targeting this specific person in this specific company, and they know who the people are, who the bosses are, who the VPs are, and they're slowly gathering information and data to craft those videos and those deepfakes.

[00:26:45] So unfortunately, I don't have a good answer to that, because I think there are multiple layers to it. There are things in the product itself, and there are things in terms of the organizational structure and systems that you have to take into account. But yeah, it's rough. I don't think there's a clear answer right now, and the fact that it's changing constantly is also a challenge.

[00:27:17] Host: Yeah. I guess that keeps things interesting for designers going forward, trying to overcome it. It's a cat-and-mouse game.

[00:27:25] Raymon: Oh, absolutely, and I think that's always true with payments, because, like I said, fraud is such a big part of it. When you're designing products in payments, you have to think about the worst-case scenarios. How might we prevent potentially fraudulent activities? How do we deal with that? What is the right balance? Ultimately, we're probably not going to get it to zero, but how can we minimize it as much as possible?

[00:27:59] Host: Well, that actually brings us to time. So I just want to thank you once again, Ray, for that talk. I enjoyed it, and I hope everybody else did as well.

[00:28:05] Raymon: Thank you all, appreciate it.