My first year at Adyen

Explaining what my job is can be a challenge for two reasons. Firstly, payments can seem quite straight forward from the outside, and as a result people don’t always understand what exactly a payment service provider like Adyen does. The second reason is that people are often inclined to imagine you sitting in a call center with one of those typical headsets when you mention you’re in a technical support team. I’m happy to report that couldn’t be further from the truth.

What do we really do?

There’s a lot going on behind the scenes whenever you click “pay”. It’s my job to understand everything that happens in the background. This means knowing everything there is to know about how our own platform and products work, but also understanding everything that happens outside of our platform to make a payment work. With this knowledge, we then help our merchant’s technical teams integrate with our platform to accept payments.

Practically, this means that merchants will reach out with questions about how to take payments for the first time, how to use different types of integrations, how to make payments using stored payment details, how to improve their authorization rate, how strong customer authentication works, which local payment methods are available, how to use our risk engine, how acquiring connections work, and the list goes on. They might reach out about integrating for the first time, but also about how to optimise an integration that’s been up and running for years. To provide some more context, let’s take look at some examples:

After clicking “Pay” while using your credit card, you might be redirected to your own bank’s page to perform additional authorization. This is known as 3D Secure authentication, a form of SCA (Strong Customer Authentication). A successful 3D Secure transaction requires communication between the merchant, your own bank, a card scheme and Adyen. Merchants might wonder how they should handle the redirection, which fields to include in their payment request, why 3D Secure was triggered for a certain transaction, in which cases the customer’s bank bears the risk of a chargeback, or even about when regulation enforcing SCA will come into effect.

Another example: when you first start a new subscription, you’ll be typing in your card details yourself. For every payment that follows, though, you won’t actually be present to enter them. In those cases, the payment can be made with your stored payment details, also known as tokenized details. Merchants can have questions about how to send in a payment request that ensures that payment details are stored, how to use stored payments details to make a recurring transaction, or how to ensure that they’re always using the latest available details.

These are just two examples, but it shows that there are a lot of different questions we might receive, and it’s my job to be able to answer all of them.

And why do I enjoy it so much?

A large part of my job is essentially to solve puzzles. Merchants will often only reach out when they’ve already exhausted their own ideas and don’t know what to do next. Many questions have more than one possible answer, any many issues can be caused by multiple different things. Of course, the more common questions or issues become familiar, but the real challenge is with cases that we also haven’t seen before and for which we have to start our research at zero. Everyone knows the feeling of finally connecting the dots after you’ve been breaking your head over something for hours. Being able to experience that during work is definitely a nice perk.

Besides solving puzzles, the fact that we spend a lot of our time speaking directly to the development teams of our merchants means we can spot trends. If certain questions come up multiple times a week, there’s a good chance we can improve the information we provide in our documentation or change the way our products work (or, unfortunately, that we’ve introduced a bug in our release). On top of that, by working with them on a daily basis, we become deeply familiar with all of our products, features, integrations and external connections. As a result, we’re in the perfect position to suggest improvements for both our products and documentation. To do this, we work closely with our product teams and technical writers. It’s really nice to be able to follow the process of improvements, from suggesting an improvement, to speaking with developers about the specifications, and finally to seeing it released.

Ultimately, the combination of solving merchant’s operational issues and helping to structurally improve our products and documentation is what makes me really enjoy what I do. We’re not endlessly solving problems and answering questions, but we’re looking for ways to make sure that the same question doesn’t arise again. We do this by improving our documentation to ensure that merchants can do more independently, and by improving our platform where necessary with our product teams. It’s difficult to squeeze everything we do into a couple minutes of reading, but hopefully this gives some insight into what I do every day. One year has flown by, and I’m looking forward to what’s next!

P.S. We’re always looking for more people to solve puzzles and improve our platform with us. If you’re interested, be sure to take a look here or send me a message.