Tag Archive for: Technology

Interview with Andrew and Rob about payments, Fintechs in Australia and what disruption really is.


The interview was held in the Paydock Sydney offices on 26th September 2018 with Andrew Stein, Founder and CEO of Payreq, and Rob Lincolne, Founder and CEO of Paydock.

Those two experts went very deep into various topics around payments, tech and business.

  • What fascinates you about payments?
  • Can and should payments be easy?
  • What is Payreq?
  • Why does Payreq use Paydock?
  • Discussion about consent and identity in payments.
  • What’s your advice to Australian Fintech founders?
  • What payments editorials do you read?

Carmen: Rob and Andrew, you are both Australian based Fintech founders in payments and before we get into the depth of it, what is it that fascinates you about payments?

Andrew: As someone who runs businesses, getting paid is the critical part of any business. You do all the stuff and in the end, you need to be paid. I have encountered issues where people do not pay you. And not because they don’t want to pay you, but they just forget to pay you, or can’t remember to pay you.

You do all the stuff and in the end, you need to be paid.

After several years of evolution in financial services we still cannot seem to get an invoice to the right person and getting it paid on time. But whenever there’s gap between the request for payment and the actual due date it creates a big impact on cash flow. You start chasing and stressing. And the smaller your company is, the more important the cashflow. After all this development of technology and all the amazing things we’re doing in technology, we’re still sending out a piece of paper or an e-mail with an invoice and you wonder, “can’t we do better than that?”. I have personally been very, very interested in and aware of this problem.

Rob: I spent a lot of my career consulting for digital merchants, particularly those, who were seeking to take payments. We saw them drowning in costs and losing control of their customers while they tried to work with the different payment services that are available in the market. Then we saw an increase in the number of payment services that are available right through to WeChat, Alipay, PayPal, and of course Visa and Mastercard. What a lot of the merchants that we were consulting for at the time discovered, was that what was on the box was not the same as what was inside the box. There were hidden fees and different ways things were structured in any time merchants tried to move to a different provider. They would constantly encounter a new set of problems, they would lose customer data, they would have compliance overheads or exposure, they would have to rebuild recurring payment programs and all of that is very hard and very costly to manager.

They simply had no agility.

We saw the opportunity in providing a thin service that took all that pain away and enabling merchants to build recurring or one-off payments against any gateway of their choice, store and manage their customers credit cards in an independent vault, managed their PCI compliance without enormous cost, and be able to scale out without fearing a lock in around cost from different gateways. So from our point of view I think, re-empowering the merchant to better work with and manage their payment services without being trapped, was a big opportunity in the market. I think particularly as we look at where the market’s going. You know we have these things like mobile point of sale and secure PIN on glass and we’re going to see iPhone’s become acceptance devices and so on. Paydock is in a unique position to be able to introduce technology providers, who provide specific niche payments technology to merchants without forcing each one of those technologies to become a gateway in their own right. Or to have to go through lengthy integration processes with payment gateways and banks who have other prioritie.

Carmen: It’s great to hear about both your niche focus in the large world of payments. Do you think payments should and can be easy? 

Andrew: Everything can and should be easy, everything. Let me go back a little: There’s actually four transactions that occur of which “payment” is merely one of them. These four transactions are:

1. The intent to buy. That is the purchase order in a business sense or the verbal “Yes, I’d like to buy your goat”.
2. Then there’s the invoice: “Ok, here is my request for the payment.”
3. Then there is the actual payment.
4. And then there is the receipt. “Great, you have given me the money and here’s your receipt.”

And in there, there’s nuances of all that: There is partial payments, overpayments, disputed payments, all kinds of things, but it’s all around those four transactions – “payment” merely being one of those. When we talk about the ease of payments, it has to be in the context of all four, because payments in isolation can be easy. I mean let’s face it, from day one, handing over cash to someone was really, really easy. Pretty simple, so why has it gotten more complex? Firstly, often we are not face to face. Secondly, we don’t have cash, we have something else. I write a cheque or I pay by credit card. It used to easy, actually it was always very easy. I mean, bartering system: Hand over three chickens, done. Now I hand over cash. Now I hand over a cheque. Now I hand over credit card. And now it is getting more difficult because of the complexities of the technology and because we are not face to face anymore.

Everything can and should be easy, everything.

And I think some of it becomes easier if you look at the four transactions, which is something Payreq is looking at, which is the second one, “the invoicing part”. The payment now becomes a lot easier because you have an invoice and you can tie the two together nicely.

Rob: Great structure Andrew. Carmen, to your question if payments should and can be easy: Yes, it should be and no, it isn’t. If we look at Paydock based on Andrew’s structure, we are very much focused on the third transaction, where we saw a huge degree of complexity and that’s what really interests me about payments too. It is now very complex and my challenge is, how do we simplify it for the merchant?

Andrew, would you put reconciliation under the fourth step in your structure?

Andrew: Yes, each of those transactions have a link and therefore “invoice to payment” is a link. And the tighter you make that link, the more reconciliation comes out. And link between “payment to receipt” means “the receipt is because of the payment”. The payment is linked to the invoice. But then in the payment you both have a payer and a payee, so there’s reconciliation on both sides. You look at that pattern, there is senders and receivers and each of those have a different set of complexities and problems they are trying to resolve. But in the end you always try to tie it to one of those four transactions. So, the receipt is tied to a payment which is a reconciliation.

Carmen:  Andrew you shared a little bit already what Payreq does. For those who don’t know your business, can you give us your elevator pitch? 

Andrew:  Payreq is a company that brings products to market that help billers to get paid on time. And I guess conversely if that’s the word, helps payers pay on time. The first product we brought to market was a biller app, which helps billers send out digital invoices to their customer’s systems that the customers want to receive on. We call those systems “payer apps” which is something a customer receives a digital invoice on, they can receive it, they can view it and it helps them to pay it. And the biller app connects to those initially third party systems. For example BPAY View is a biller app embedded in your online bank. PayPal is a third party system that you can send or receive a request for payment on. If you’re a Chinese citizen you might use WeChat or Alipay and so you can receive a request for payment of an invoice on those two platforms. So those are third party payer apps. Our first product , the biller app, allows billers to send digital invoices to the customer’s preferred payer app.

Carmen: Which countries do you currently operate in Andrew?

Andrew: One is obviously Australia, you know building in your backyard, trying it out. Australia has a number of reasons why it is a really good place to do stuff. And we’re also in Canada, which we chose because we found some similar payer patterns there. They have something called epost in Canada and our first payer app we connected to was BPAY view here in Australia.

epost, run by Canada Post, had a similar pattern and similar set of problems as BPAY View had here, which effectively is a great payer app, but not many billers to connect to it.

By putting our biller app into Canada we opened up epost and made it much easier for the biller to offer epost as a delivery channel for invoices.

Carmen: Thanks Andrew. You are an existing Paydock customer. How do you use Paydock and why?

Andrew: Rob already touched on a few things that attracted us to Paydock in the first place. We have global aspirations for Payreq. It’s a global platform. Billers send invoices to the world and customers everywhere. The challenge we had, is each country has specialized payment gateways and services. Because of the single platform model we run, we didn’t want to have bespoke connections in Canada to Moneris for example and another one in the U.S.,  another one in Australia, another one in Sweden and so on. We don’t want to build all of these bespoke things and for us one of the features of Paydock is that we can connect to Paydock once and having configuration rules put in place. For example: “A customer has signed into the Canadian Payreq account, now we use the Canadian gateway of choice.” We can keep it in the country, keeping the foreign fees down for the poor payer, who may not know their pumping fees to a foreign gateway and all these sort of things.

It essentially allows us to have full flexibility with multiple gateways around the world. But we only had to integrate once. That was really what why we decide to integrate into Paydock versus into the default gateway.

And the second thing why we use Paydock is that when you have lower volumes some gateways are more efficient to use than other ones. So, if you go with a gateway that doesn’t have a monthly charge but only charges for transactions, then that’s more efficient at the beginning. However, you might want to switch to a gateway that offers a monthly charge and a much lower transaction fee once you feed through lots of transactions. So how do you do that? It’s very expensive and time consuming to do the work in-house, but with Paydock we can just switch it one day.

Paydock essentially allows us to have full flexibility with multiple gateways around the world. But we only had to integrate once.

The third reason is that the only way you can switch gateways like that very flippantly and without impacting the customer, is if the credit card is stored within some neutral third party like PayDock versus a gateway. Because one of the things a lot of people don’t realise is, when you go to a gateway and you save credit card details in the gateway, the gateways are the ones who are storing your credit card details. To then switch gateways, you potentially have a data hostage situation where the gateway says “Well you know, we have all your credit cards for your customers. Are you sure you want to switch?” And it may turn out very costly or really hard to move the customer’s credit card file to the new gateway. So worst case when switching gateways, is you make your customer re-enter all their credit card details, which is just a bad experience. A number of those features Rob touched on are attractive to us for different reasons.

Carmen: Thanks Andrew. Rob, I know that Andrew is a very generous customer when it comes to giving honest feedback. As founder and CEO of Paydock, how do you embrace that?

Rob: I want it. Actually, it’s one of my favourite things about Andrew (laughs). I hope that Andrew never stops picking up the phone to tell me, that this and that needs to change. a

Carmen: I know that there’s a topic you both like exploring in your own time but also together, which is “consent and identity in payments”. Could you tell me a little bit more about that? 

Andrew: Well, let’s look at a pay request: Obviously as a payer I consent to pay you, the payee, money. So there’s a consent there, that’s obvious. But then, when we look at direct debit, the payer gives the payee the consent to pull money from the payer. Now let’s say the payer wants to stop their gym membership. How do I stop that all of a sudden, how do I un-consent? It’s difficult. And then the identity-side is interesting. If I go back to sending a payment to someone, how do I know whom I’m really paying? In the worst case, the person on the street wearing a koala outfit says “Hi, I’m from World Wildlife Fund. Give me a hundred dollars in my bucket.” and I say “Sure, but who am I really paying?” I consent to give but who am I really paying? Identity of the payee is really tricky and there is all kinds of fraud out there. We read in the papers of people paying someone who they think they’re paying cash to. But in fact, they’re paying a fraudulent party. Identity is really important in payments.

We read in the papers of people paying someone who they think they’re paying cash to. But in fact, they’re paying a fraudulent party. Identity is really important in payments.

And part of the solution, if you look just at the payment, is kind of hard. But if you tie it to the four transactions then, when you receive an invoice from someone you merely say “Oh, I haven’t paid anything yet, but I can see who I received it from or if it is someone pretending to send me an invoice.” And this is where you start getting into these solutions, the complexity of technology. How do I know when someone sends me an invoice that it really is from Telstra? I received an email from Telstra, but I don’t know, it could be fraudulent or it could be real. They’re all over the place, these scams. They’re everywhere. We conclude e-mails are a really bad way to prove the identity of the sender. But in the digital world, where Payreq lives, it is the digital systems that are sending invoices instead of e-mails and there’s a much higher level of identity baked into these digital systems. So if you register with Telstra in BPAY View, there is actually a consent saying to Telstra “Please send me my future bills to this payer app called BPAY View where I live at Westpac.” Telstra sends me the bill and based on my consent I know that it is truly from Telstra. The BPAY View payer app world is run by the banks, so it has KYC AML all baked into it and that way I have consent and identity on both sides. Telstra knows it’s me, their customer who has consented, because of the nature I’m doing it through my bank. The identity consensus is really important for senders and receivers and all transactions, but certainly around payments and part of the solution is around the requests for payment.

Rob: Consent and identity? We have a saying at Paydock “We are agnostic as what constitutes in exchange for value”. So as long as the two parties agree on what is being exchanged and what the value is, it doesn’t matter if it is Dollars, Qantas points or some Bitcoin. So at this point where the two parties come to an agreement, then consent becomes very important about what is it you are agreeing to. And then verifying that these two parties are who they claim to be is also very important. Let’s look at it from a payments point, based on point three of Andrew’s transaction structure in the form of payments acceptance:

We have 3D Secure, we have got pin codes, we have face ID, there is just so many different mechanisms out there to try and establish identity. And the complexity comes with digital payments and the ability for fraud to creep in.

Because you can’t actually look the person in the face means that finding ways to verify identity is very important.

And to your point Andrew, where I trust the bank, then that’s my source of trust. The question is, where do I have my trust anchor. And are banks going to continue to be those trust anchors?

Andrew: Well, that was only one example of how it works in the BPAY view payer app. If you’re on WeChat or Alipay, then there’s a different trust anchor. In this case your social media is your footprint that proves who you are. So, it is just an example how one payer app solves it – and in this case you need to trust your bank which is higher than an email you receive. It’s just that every payer on a payer app or a billing app, has to identify. I guess our question around those apps is, what is their strength of identity, what’s the strength of consent?

Rob: You said something a while ago, about “de-identifying” yourself, what was that about Andrew?

Andrew: Oh yeah, it’s not about knowing who you are, but it is actually the opposite, where I don’t want to expose who I am.

Rob: What role does that have in payments? Do you have to know who somebody is?

Andrew:  In the world of Bitcoin for example, there is no identity. In the end this is a strength and why people are attracted to it, because there’s no identity. It’s just I received it anonymously. It’s interesting because on the one hand you go “Oh that’s really cool.” And let’s be honest, cash was the original “You have no identity.”- cash was the value transfer. I could leave an envelope with cash for you and you have no idea who I am.

Rob: It’s okay if you want to do that too by the way. (laughter)

Andrew: The interesting thing is, if there is no identity in payers and payees, on the one hand we think that would be cool, but on the other hand it would just lead to so much bad stuff. If you imagine every rule we have whether it’s AML, or you cannot donate x amounts of dollar to a political party and all this. If there was no identity, you couldn’t have any restrictions and people would just be sloshing stuff around and no one would know anything.

It would actually be financial anarchy if there was no identity everywhere.

Rob: But what if that identity was de-personalised and had the correct trust anchors, would that be sufficient? So, you would say “This party has the so-and-so verified tick, I know they’re safe, I don’t know who they are but I know their silhouette and it’s safe to pay.”

Andrew: But you’re really putting your trust in a third party here. So, the third parties know who the payee is. What I mean when I say “de-identify” is that I would as an individual, “de-identifying” all transactions but payments. For example, if I go and get a quote for a credit card or for a home loan, they don’t need to know anything about me, just some parameters, maybe my income. But they do not need to know who I am. But as soon as I do the payment or they lend me the money, you have to have identity. I’d say “de-identify” outside anything but payments.

Rob: I agree with you. And I’ve been turning this over in my brain: How is identity manifested? And where is the trust and what do I actually need to know to establish that trust and who from? But the other side of that is consent. For example, if you want to make a recurring payment on WeChat, you don’t have a system there, that automatically takes money month on month from you on a subscription, but you actually have to consent to that payment month on month. So, you’ll get a push notification that says “So and so requested a payment, are you still cool with that?” I see a lot of the industry going that way.

Andrew: That’s exactly what Payreq is about, you approve the request. So, if someone said they would like some money from you and you reply “yes” to this request. Now, you can make your life easier and set up an auto approval. But you, the payer sets that up. And you could cancel it any time. That’s your choice. The person on the other end doesn’t have to know whether you as a human being actually said “Yes, approve”, they just know you approved whether you set up an order rule to approve it or not. It’s your business. My flippant headline answer is, that we will stop paying each other, but that we will be replying to a repayment request. There’s no more payments on its own. You want to be paid? Send me a request and I’ll decide. And that gives me context, that gives me who the identity of the payee and I can consent. So even the guy in the Koala costume that comes up to you asking if you can donate $10 to WWF, I ask him to send me a request. This transaction now includes the consent to pay and the payer’s and the payee’s identity.

Rob: Do you think that still works when we have like 30 different request per month? I am thinking of all the platforms, like Netflix and Spotify, I am signed up to.

Andrew: One thing you need to separate, is the legal contract and the payment. Foxtel might want to lock me in for 12 months, which I legally agree to. But what they try to do is link it to the direct debit. Now, what I’m saying is that they are two different things. Legally, sure, I’ll take it up for 12 months but if I decide to stop paying them, well that’s a different thing. That’s a legal problem for Foxtel, not a payments problem. In the world of Foxtel the idea is that I legally agree to a 12 months subscription or as the world is moving to a “pay as you go model”.  Anyways, the idea is that Foxtel sends me a request every month and I’ll pay it. And to make my life easy I set up an auto pay rule – or maybe I won’t. But the thing that I can do, is that I can decide this month to pay off my credit card and next month pay off a different credit card. And then next month pay off whatever. So, it’s kind of separating the legal contract to take the service versus the payment per month versus the source of funds. It’s deconstructing those things as those have always been linked together.

What I mean when I say “de-identify” is that I would as an individual, “de-identifying” all transactions but payments.

Carmen: That was great guys, thank you. Let’s move on to my next question: What is your advice to other Fintech founders and leaders in Australia? 

Andrew: There’s two types of Fintechs out there: There is those that go into a space where they see money to be made, and certainly often around payments. And the second one is a Fintech, that goes into a space because it’s truly innovative. Let me give you examples: There are Fintech companies all over that will lend you money, for literally anything: Education, home loans, small invoices, you name it. All of these lending companies are after the interest in the transaction. And I’d say, they probably all be Billionaires in a few years time, but is that innovation? This is where I’m a bit snobbish because in my opinion that’s not innovation, that’s just doing the same thing we’ve always done, just adding that “tech veneer” over it. However, my tip to any Fintech founder: I think Australia’s a great place to try things because it’s a hard environment. I have been told numerous times that if you can succeed in Australia you can succeed in the world. It’s a hard place to grow up. At the same times it’s a small country, so you can get out there and meet people inside a bank easily. It’s not like in the US, trying to meet the CEO of the Bank of America, which is impossible. So there’s pros and cons to starting a Fintech in Australia, but if you can succeed here, I think can succeed anywhere with great.

Rob: I think there are Fintech founders, that see an existing model and try to iron out kinks and optimize and somebody else’s margin is their opportunity for businesses. But I don’t think that’s innovation. I think innovation in Australia, is a really tough gig. Because we are a country that loves the status quo and if you want to change the status quo or change the narrative, you either need to be very tenacious or very rich. Maybe both. So, my advice to those founders who want to try something new is manage your risk, be tenacious, don’t expect too much love from the market and stick to your customers. Understand the problem you’re seeking to solve for them. Make that as valuable as possible, so you’re delivering happy customer, you’re delivering value. And I think in order to nudge the status quo, take a lead from “Crossing the Chasm” (Book by Geoffrey Moore): If you are in the B2B world like Paydock, you need to deliver significant value to stay in the game. Otherwise the status quo will just carry on. But fortunately, because payments is such a complex world, there is value to be created because it’s highly complex and it’s hard for people to understand. And if you can turn something complex into something simple, understandable and approachable you’ll always find an audience.

I think innovation in Australia, is a really tough gig. Because we’re a country that loves the status quo.

Andrew: I agree Rob. Being a disrupter in Australia is really, really, really difficult because of the status quo and the culture here. Being an enabler is a much more interesting space, and I you can still enable and bring innovation.

Rob: I don’t even know if you can be a disrupter in Australia unless you have the network. And you can’t have a network unless you are enabling one way or another. If you come in and “disrupt everybody” then that’s probably the final nail in your coffin in the market  #laughter

Andrew: Yes, I don’t even know if you can create new stuff in payments, because we’ve been exchanging value for goods forever. You can certainly carve out big niches, but can you be truly disruptive? I mean, you look at Twitter and Facebook. They were not disrupting anything, they created a whole new category. We often talk about future jobs and things, and there will be jobs out there that we haven’t even thought about. They won’t be disrupting or taking anything, but they will be completely new, solving new problems that we never ever had before. So, I think disruptor implies that you have an existing place that you’re disrupting but outside of Fintech for so many places, there is whole new products and worlds being created.

Rob: Do you think though, now that they – Twitter and Facebook – have the network, they could actually disrupt? They could introduce the “Facebook Bank” and that would disrupt something. But at the beginning, when you create something new, you don’t really disrupt anything, right?

Andrew: Yes, that’s right. I could keep exploring this forever, but let’s move on.

Carmen: My last question for you guys: What is your go to source of truth when it comes to the latest and greatest payments news?

Andrew: There is a bunch of news feeds and things that I sample, but to be honest, there is just a lot out there and it is just a lot of noise. Things that are trumpeted as news, is actually just an iteration of something else. In the end you actually need to get on with what you do. I think with emerging technology companies, you have to be aware of what’s happening in the world, but you can’t stop it. And all you can do is, innovate, focus on your day to day stuff and what your key spaces are and keep getting feedback from your customers. I actually think that for a Fintech founder, payments news, may just be a distraction.

Rob: I think I agree with you. It is a distraction on one hand. On the other hand I do get some of my creative inspiration from seeing the way other people are trying to solve common problems. And the way people deal with identity and consent and recurring payments and payment times and customer experience and all that is very interesting to me. But of course, if I spend too long looking at it, it becomes a massive distraction. One thing that I’m looking out for, is seeing how other people try to solve the problem that Paydock is trying to solve. Having external points of reference to demonstrate that Paydock has competitors says this is a real issue and is an important part of a narrative.

“Never compare somebody else’s outside to your inside.”

I like www.pymnts.com and glance over that email in my Inbox each day. But back to Andrew’s point, we have customers to support and listen to. And you know I could spend all day just looking at what other people are doing and not actually building our own business. I remember this saying: “Never compare somebody else’s outside to your inside.” And as business owners it’s easy to look at all these shiny headlines of other Fintech’s and there’s all these things you want to do, but truth is stranger than a fiction for those who keep their heads down and just persevere.

Carmen: Thanks guys. Any last words of wisdom before we end here? 

Andrew: In the Jane Fonda movie “Logan’s run” everything just worked. There is this complex machinery, but it somehow just maintained itself and worked. And that’s where we’re moving to: You turn the light switch on and light comes on, you turn the tap on and you get fresh water. And in the world of Fintech and payments, there is so much complexity, but the idea is that we just make it work. So that people in the future don’t have to think about the process but it just works.

Carmen: What a great way to end. Thank you, Andrew and Rob for sharing your insights and experience. Good luck making this world of complexity easy and simple.

–> Want to know more about Payreq? Check them out here.
–> Want to know more about Paydock? Contact us here.

We’re excited to announce we’ve released our .Net core SDK for Paydock. This is SDK makes is easier to use Paydock from any of the .Net based languages and deals with a lot of the plumbing necessary to make the HTTP calls.

You can pull this down through nuget (.Net 4.0.Net Core) and the code is open source on github.

Supporting .Net Core

We released our .Net 4.0 SDK earlier this year. We targeted .Net 4.0 as this was the most immediate need and most of our customers were running on .Net 4.0-4.5. However, we knew we’d also want to provide good support for .Net core.

When we built the .Net 4.0 SDK it was based around supporting the maximum number of developers, which limited our options. With the .Net core SDK we had more freedom to use more modern libraries and tools. The question for us was to find the best way to support both.

Option 1 – Complete re-write

We could release a completely new SDK, re-written from scratch. This would mean that we could choose the best tools, unencumbered by any limitations of .Net 4.0 era. However it would mean no re-use and any changes to the SDK would immediately have to be applied to both core and 4.0 SDKs.

Option 2 – Single codebase

We could completely re-use the codebase. This is a little problematic as some of the features used by the 4.0 SDK were not available in Core. We could handle this with pre-processor directives, however that can become difficult quickly. It also meant we could not support features asyc/await.

Option 3 – Partial Sharing

We could share some parts of the SDK between Core and 4.0. Essentially the .Net 4.0 SDK is: a HTTP wrapper, Models for request/response, helper classes and service classes that glue it together. Some of these can be completely shared (e.g. models), however others (e.g. HTTP wrapper) are more complex.

In the end, we decided to select this option.

Tech Details

Given that we’re sharing part of the code, it made sense to keep this in the same repo.

However, for ease of building the code, we split this into two separate solutions. For the .Net core app, we shared the code files as links, which meant we could add the Core SDK without significant restructuring to the existing codebase.

Functionally the two SDKs looks very similar (just add await), but under the sheets there are quite a few differences, including a heavier use of generics in the .Net core SDK.

We welcome feedback and we’d love to hear about how we can do this better in the future, feel free to raise an issue on github.