Theo Spyrides: Welcome, André. To kick us off, what are the first steps when setting up payments in a new business?

André Moeller: Really good question. If you get the possibility to set up new payments in an environment you're working for, the first important thing is you have to start from the product side. What does that mean? How big is your average basket? What customers are you talking to, and what's your target group, because it's different depending on the generation. The older generation is more related to credit cards. The younger generation is between credit cards, PayPal, and for Gen Z, it's more related to TikTok, WeChat, and open banking. So the important thing you have to cover on your roadmap is: what's the product, how big is the average basket, and then you set up the payments accordingly. I started my career in the gaming industry, where you have very low baskets. The target group is under 20 on average, so most people don't have a credit card, they use alternative payment methods like Paysafe or PayPal. A couple of years ago I was in charge of payments at a DIY store, where the baskets were bigger, averaging 300 to 400 euros. The target group there is house owners and DIY guys, and they're more related to credit cards, not so much PayPal. So it all comes down to: what's the product, what's the target group, and what's the average basket. Based on that, you start designing your payment setup.

TS: So it sounds like you need to understand your customer, and once you understand the journey you want them to have, you can define your payment strategy. I'd love to understand what impact the average order value has on how you'd devise that customer journey?

AM: It's important because we have different products. For example, we provide e-commerce stores where customers buy an EV charger. There, we use CIT, customer-initiated transactions. In the world of payments there are two capture ways: CIT, where the customer has a basket with a volume and you ask "is this customer allowed to check out with this payment," and you get a green or red. On the other hand, we also deal with charging energy for drivers, and there we're in MIT mode, merchant-initiated transactions. We get the information that the customer has charged, and then we send the capture. These two ways define, in the end, how I design my payment process. If you're going the MIT way, the volume of the basket you need to capture is very important because of credit card limits. For example, if a customer goes from Germany to Spain in 18 hours, he might have four to five or six charging sessions depending on how fast he's driving. In that case you send five to six captures to the customer's payment method within 24 hours. So on one hand the customer's credit card might not have a big enough limit, and on the other hand the issuing bank can decline your captures because they think it's fraud. In the CIT way, you always have a basket with a product, you ask "is this customer allowed," and you get yes or no. If not, the customer can't check out. In the MIT way, in the charging environment, the customer is done with the transaction and we get the information that we now have to capture. There are many ways captures can fail, and we have to cover that. The amount isn't huge, roughly between 35 and 45 euros, but if you send more than one capture during vacation periods, they can mark you as fraud. So it's trickier and riskier than CIT capturing.

TS: That makes complete sense. So each business is different, it's not one-size-fits-all, and you really need to understand the customer journey and the payments experience around it. Do you think there are any common pitfalls to avoid early on when building out a payments system?

AM: Definitely, yes. As I mentioned, you have to look at what product you're selling and what capture method you're working with. If you're starting from scratch, there are common pitfalls you can prevent by thinking it through early. Most companies define their products and verticals but miss out on payments, risk, and fraud. I've seen this happen more than once. We can help a lot in planning shops, capture flows, and payments/risk/fraud processes. It's important that the company understands what they're doing, and that they talk cross-functionally with different departments. Payments is always a cross-functional department. It's not just related to product or finance, it touches every vertical: product, finance, accounting, debtor management, customer care, whatever it is.

TS: That's a really nice way of thinking about the payments team as being cross-functional, touching the entire business cycle. Does that mean you see payment teams as consultants, builders, or both?

AM: Yes, both. We always see my payment team and myself, in daily business, as consultants, because we have to keep an eye on the market: what's new in regulation, new payment potentials, fraud risks, protecting and defending our systems from fraud, and so on. That always has an impact on the product, on terms and conditions, and on customer care. If a customer calls customer care saying "I got a dunning letter because you can't capture my money," we have to support customer care in explaining why that happened, so the agent on the phone can see, "oh, your credit card limit is exceeded," or "your credit card is expired," or "we got a technical failure from PayPal." Product also needs to know what they can do with different baskets and capture methods. Finance needs consulting from us to get the right numbers, like how many captures failed, how many settled, so they can build reports. It's always back-and-forth communication: we bring information from the market and from regulators, and let the verticals know what they need to change in terms and conditions, invoice emails, and so on.

TS: And it sounds like there's a high level of collaboration required. Do you think that healthy friction ever becomes unhealthy? How do you view that, especially as the payments function scales as the business grows?

AM: Definitely. If I had to bet, I'd say more than 50% of communication failures come down to who is doing what and who knows what. Departments often forget about payments, risk, and fraud. For example, last week a colleague called me for the first time and asked a bunch of questions about terminals and technical suppliers. I was thrilled that he asked before doing something, because it gave us the chance to consult him and set him up to move forward the right way.

TS: I think the most obvious touch point on that customer journey, and one that requires a lot of collaboration between the payments team and product team, is checkout. How do you think about the optimum checkout process, especially solving for the customer, as you said earlier?

AM: I can't give a single right or wrong answer for the perfect checkout process, it depends on the product. First, is it a physical or digital product? Then, which capture method: CIT, where the customer has a basket and you ask if the payment is valid, or MIT, where the customer is gone and we send the capture afterward? In e-commerce, you go through the shop, fill your basket, and get to the checkout where you need to check out fast. In the MIT or charging business, there's an onboarding process where the customer first gives you all the information: name, address, city, zip code, phone number, email. Sometimes he has to submit an email before moving forward, then choose a tariff, then insert payment, and the checkout process starts. So it's less a checkout process and more a process to get the customer into position to charge the car. In both cases, don't overload the customer with payment icons. In e-commerce, screen space is limited, more and more on mobile, so screens are getting smaller. If you have 20 payment options, it's overwhelming, the customer is thinking "what is this, I've never seen this," and that leads to cart abandonment. In charging, you only have a small phone screen, which is also tricky because you need to show, in a very short window, which payment method the customer can use for the subscription. In both cases the common thread is: don't overload the customer, make it as simple as possible.

TS: And on payment methods, with the mantra of keeping it simple, how many payment methods are too many?

AM: It depends on the product, the customer, and sometimes the country. If we're talking about Asia, China specifically, you need WeChat and Alipay, so that's two. In Europe, you typically have credit cards, PayPal, and Amex, which I'd group with credit cards. So four to five payment methods is the sweet spot from my point of view, across countries. In the US, most people use credit cards, but also PayPal and Apple Pay, which is tied to credit cards. New options keep coming up too, like open banking, account-to-account payments. So four to five max, in my view, is more than enough. More than five will confuse the customer because they have to scroll, and the customer shouldn't have to scroll, they need to check out. So four to five max, regardless of product, country, or CIT/MIT.

TS: How do you choose which ones to show at checkout? You mentioned regional considerations, no point having WeChat in the UK, for example. But how do you build out that portfolio of payment methods per region?

AM: It's the chicken-and-egg principle, but not always. Take WeChat and Alipay in France, for example: big brands like Cartier or Louis Vuitton don't have that many customers ordering online from Asia or visiting from Asia. But if they don't offer WeChat and Alipay, those customers won't buy anything. So sometimes the chicken-and-egg logic doesn't apply, coverage matters most. For example, we had a payment method in Germany called giropay/paydirekt, which shut down last year, because of that chicken-and-egg problem: the customer asks "where can I use this," and the merchant asks "how many customers do you have." Checking the market penetration is a good way to gauge that. In our charging world, we're a bit more flexible. My wife, for example, shops online and sometimes uses PayPal, sometimes Klarna, sometimes credit card. In charging, the customer chooses a payment method early on, in a subscription mode, and ideally doesn't change it. So you get one shot to ask the customer which payment they want. In e-commerce, every time the customer comes to your shop you have the chance to show alternatives, like Wero, which is coming up now in Germany and Europe. So sometimes I decline the chicken-and-egg principle, and sometimes it's worth being a first mover to support something new, like Wero.

TS: And as a merchant, if you are that first mover, what are the benefits?

AM: In most cases, marketing value. But with something like Wero, I think there's a genuine positive case for being a first mover, because it has backing from the European Commission and European banks to bring a competitor to US brands to market. It's not necessarily an alternative to PayPal, it's an alternative to US brands generally. We're in a political situation now with an "America First" strategy from the US president, which could be negative for us in Europe, especially in payments, because of US brands controlling US infrastructure. We need competitors in Europe to keep our data and customers in Europe. So in that case, I think it's actually a good decision to be a first mover.

TS: Makes sense. As a merchant, I need to think about customer conversion, coverage for all my possible customers, payment journeys and flows, and costs. That's a lot to consider. How would you advise a merchant to go on that journey to make the right decisions, and how do you validate you've made the right ones?

AM: I always use process design to build an end-to-end process, from the customer entering the shop or onboarding, through to dunning and debt collection, and make that whole process visible. Once you see the whole process across verticals, you find the gaps. Did we miss risk and fraud in onboarding? Do we need risk and fraud in lifecycle monitoring? How do we handle a failed capture? Do we need an automated process that sends dunning letters from the ERP, and after a third letter, hands it to debt collection? Do we need an external partner, or can we cover it internally with ERP and CRM systems? That's how you build the whole picture without missing anything, and part of that is asking the product: what's your basket, what capture method do you need? That feeds into dunning too. For example, we have a highly automated dunning process for charging because of MIT, but for our shops we don't need one because we use CIT: if you don't have the money, we don't send you an EV charger.

TS: How much does data contribute to all this? Once you've mapped your process and understand the flows, how do you bake data into your process and strategy to optimize those decisions?

AM: Data is one of the most important pieces of this whole setup. For example, if a customer is charging on a vacation day, going from Germany to Spain, it's normal for him to have five charging sessions within 24 hours across four countries: Germany, Luxembourg, France, Spain. Data tells risk and fraud that this is valid. But if a customer charges the same day in Germany, the UK, Romania, and Greece, that's not legit, and data flags it for risk and fraud to investigate. Data also shows average basket size and average charging sessions, which feeds into fraud prevention. Say the average basket is 15 euros, then one month it jumps to 55 euros. Why? You look into the data, maybe it was a holiday period, that's fine. But if it's November, not a holiday anywhere in Europe, you need to dig deeper, something might be wrong. Data shows us what's right, what's wrong, how fees are trending, how transactions are trending. Data is the DNA we need. It's the blood in our veins.

TS: That's music to my ears, especially with a maths degree. André, that's all we have time for today. One last question: if you had to give advice to a merchant building out their payment strategy in a new business, what would it be?

AM: First, find the right payment person, someone with real payments experience. I've been in the payments industry since 2007, and I've seen so many companies think "payments are easy, we can do this ourselves." No. Every one of those companies realized after six to twelve months that they needed someone experienced. There's no university course for this job, it's learning by doing, and there are people out there who've been in payments, risk, and fraud for years who can teach colleagues and teams. So, hire the right people, build the right team, think about payments as well as risk and fraud, because you will have fraud, there's no scenario where you don't. Set up the right team, map the process end to end, and bring all the stakeholders together: product, finance, customer care. Handle the payment team as cross-functional, and you'll have the right end-to-end payment process.

TS: Fantastic. Well, thanks so much for sharing, André. Great speaking with you.

AM: Thank you so much for your time.