Payments @ Picnic

This interview was co-authored together with paymentspaymentspayments.com

About you

Hello, I’m Jelmer Borst. Analyst by heart, background in aerospace engineering but favoured the fast pace of tech start-ups over traditional engineering companies. Supermarkets have limited margins, so as a product owner of the Payments & FinTech team at Picnic, the team and I are trying to solve the puzzle to achieve the best checkout experience for the lowest price.

Picnic is rethinking the way people buy food. Without physical stores, we use an app-only approach and a user-centric philosophy, to make grocery shopping quick, simple, and fun.

Starting in one Dutch town in 2015, we now serve over 60 cities in both the Netherlands and Germany. The secret to our success? An end-to-end business and a just-in-time supply chain. From the app-only store, forecasting of orders, warehouse fulfilment, to the evolving distribution strategy of our fleet of electric vehicles, we build everything in-house on our self-developed software.

How does operating in the Netherlands impact the direction of your payments architecture?

Picnic started out in the Netherlands. Unlike in many other countries, credit cards are not really common around here and debit cards don’t have the 16-digit PAN to use online. The common way to pay is through a system called iDeal. Think of it as doing a card payment, without requiring any input (no PANs) aside from choosing your bank (from a small, provided list) and always have a 3DS flow. As this payment method already exists for many years, the “3DS” flow is very optimized by using a simple app switch.

Fortunately, methods like iDeal do not require PCI compliance and apart from a bank name, we don’t need to store anything to make the payment happen. As you can imagine, by not needing to think about PCI, it’s rather convenient to route the payment to any payment provider. Additionally, from an architectural standpoint this decouples the integration with a PSP and our payments service, therefore allowing us to scale quickly.

We found that there’s a significant difference between providers (and their providers and the provider’s providers) in uptime and auth rates, so it becomes crucial to optimize both as much as possible. We are all creatures of habit and as we’ve been going to the supermarket our entire lives, our customers need to get accustomed to their new habit. But that means if you, as a customer, cannot finalize your payment, you’ll drop out, go to the store around the corner, and there’s little chance you’ll come back.

Are you optimizing which provider you use in flight or is that something that’s constantly being tweaked for best results?

Currently it’s the latter, but we’re looking into in-flight routing. That’s not necessarily real-time by the classic definition. Namely, the current performance of a provider doesn’t alter the routing of the next payment, yet the historic performance does. For example, all requests in the last X minutes for a given segment (bank, auth rate, amount, etc.).

Additionally, you’ll want a retry strategy. On failure of provider 1, go to provider 2 and try again. This doesn’t alter the routing of the next payment that comes along, but does reduce failure rates and thus increases conversion & retention.

What do you think the main advantages and disadvantages of iDeal are for a product with limited margins?

iDeal is a fairly convenient method. Most banks have a decent UX and customers feel in control. Pricing is also cheap compared to credit cards, so we’re pretty lucky there.

At Picnic, we obsess over improving the user experience by removing friction as much as possible. We learned through experimentation that this has a positive impact on user retention. For companies that have limited margin, this is important since the loyal customer base drives profitability.

Unfortunately, iDeal introduces too much friction. So even though costs are lower than cards, it’s missing crucial elements to be the de-facto method for a recurring business.

Recently, iDeal celebrated its 15 year anniversary. This reminds me of the fact that it was designed in a time where online payments were new and people were accustomed to wire transfers. If you would design a new method from the ground up, today, it would work vastly different.

Speaking of new payment methods, can you share a bit about the Maestro debit card that Picnic is piloting? What are some of the major benefits?

Absolutely. To start with a bit of context: the Netherlands has very limited card payments. And if people pay with their card (PAN), it’s only credit cards. For some reason, our debit cards only contain the IBAN but not the PAN. Though, of course, there’s a PAN! It’s just not printed. Interestingly, VISA (and its debit sub-brand V Pay) barely exists here; MasterCard completely dominates the market with their Maestro sub-brand.

Additionally, ordering groceries is a pretty complex process. For any given delivery, it’s common to order multiple times (forgot my toothpaste, oh let’s add some milk, oh and friends are coming over: let’s add some wine) and to have a refund process. As a customer you pay a deposit to encourage plastic recycling (by law in the Netherlands and Germany) and thus if you return them in the next delivery, you get your fee back as a refund. So it’s not uncommon to have 5, maybe even 10 transactions per delivery! Your bank statements are an absolute mess…

Now, some time ago we came in touch with MasterCard Netherlands to design a payment method from the ground up for the maestro debit card. To make it a reality we needed a PSP and bank to support it so we partnered with the folks over at Adyen (one of the largest PSPs and who are only a few blocks from us, in Amsterdam) and Rabobank (one of the three big banks in NL).

As Picnic we often use the analogy of the “modern milkman” — whom you know on a first-name basis, whom you would even trust with the keys to your home, and who lets you pay next time because you forgot your wallet. We have a similar relationship with our customers. So if you trust us, and we trust you, why don’t we trust your payment?

This led to creating the following principles in order to create our perfect payment method (also internally dubbed ‘Picnic Pay’):

1. One-click payment (only exceptions require authentication)
2. Seamless, one-off enrolment (no data entry required)
3. One delivery equals one bank statement (through auth-increase and partial captures)
4. Customer-first service with instant refunds (no cure, no pay)
5. No sensitive data storage (and thus no security vulnerabilities)

Nevertheless, this method is not Picnic-specific. There are many more use-cases from other merchants that can benefit from this. So even though we started out first, other merchants will follow later this year.

If you’re curious about the underlying technology: we’ve built this on top of MasterCard’s tokenization service and MDES.

That sounds pretty neat! Given that it’s so seamless, doesn’t that lead to issues with fraud?

As you read above, being a supermarket has its challenges due to low margins, etc. However, it also has its benefits! As we’re not selling international flights, iPhones or other high value items, there’s very limited benefit to committing fraud. We’re selling bananas, after all! Therefore the improved UX — and thus conversion & retention — definitely outweighs the risk.

Nevertheless, like any card there’s still a possibility to use 3DS for authentication. At Picnic, we evaluate payments on a case by case basis and might request additional authentication to ensure the safety of a customer payment.