Latest / The Payments Shed / Ep. 49 - Live from MPE Berlin: BR-DGE on Payments Orchestration - Why Merchants Want Control of the Stack

Transcript

Ep. 49 - Live from MPE Berlin: BR-DGE on Payments Orchestration - Why Merchants Want Control of the Stack · The Payments Shed

• 0:02
  Welcome back to the 5% podcast live here at MPE.
• 0:05
  We're joined by Jacob Spencer, Sarah Bridge.
• 0:08
  Jacob, give us an introduction. Tell us something more about
• 0:09
  yourself and and bridges of business.
• 0:11
  Yeah, thanks a lot. So myself, I joined Bridge five
• 0:14
  years ago almost to the day. At the time, we were tiny.
• 0:17
  We were probably like 6 people, seven people.
• 0:20
  Since then we've scaled, we've grown, we've grown a book
• 0:24
  predominantly serving highly regulated and regulated and
• 0:28
  market gaming merchants with pay, insurance and payouts
• 0:31
  optimization and connectivity. We've also got a wider book that
• 0:35
  does e-commerce with brands such as the Hook Group within it.
• 0:38
  And we also work with some travel businesses and other
• 0:40
  businesses like high volume ticketing events.
• 0:43
  The key thing for ourselves is that the strong markets that we
• 0:46
  work in, UK, Ireland, Europe, Australia and moving into North
• 0:50
  America and the reality is we serve enterprise merchants who
• 0:54
  are looking to solve complex infrastructure challenges.
• 0:56
  And when we talk about orchestration, what kind of what
• 1:00
  does that mean to you? Explain what it means.
• 1:02
  Yeah. I mean, I think the critical
• 1:03
  thing is, you know, a lot of people get a bee in their bonnet
• 1:06
  about saying that's not true orchestration.
• 1:08
  Now I actually think to to most degrees payment technology does
• 1:14
  orchestration, but on certain facets and certain things.
• 1:17
  So I don't think there's anyone true definition, but I think in
• 1:20
  terms of what we actually feel we do, we're a piece of
• 1:23
  middleware that sits between the merchants, you know business and
• 1:27
  forward facing infrastructure and downstream payment service
• 1:30
  providers. Now where we feel we
• 1:33
  differentiate is we don't try to be, you know, quote UN quote the
• 1:37
  last payment integration they ever do.
• 1:39
  With some merchants that is the case.
• 1:41
  You know, we can service the entirety of their their payment
• 1:43
  requirements. But for most of our merchants,
• 1:46
  we will come in, we'll understand problems they've got
• 1:49
  with their payment infrastructure and we will solve
• 1:51
  through orchestration the aggregating the implementation,
• 1:55
  the optimization of traffic flow for certain facets.
• 1:58
  Now for most merchants that's card, it might be solving
• 2:02
  tokenization challenges, it might be bringing that all
• 2:05
  together. But I would say we are an
• 2:07
  independent piece of technology that brings together lots of
• 2:09
  payment services in a harmonious way.
• 2:12
  And I think a lot of people do that, but they might do certain
• 2:14
  facets, be that acquirers, be that open banking providers, be
• 2:18
  that fraud providers. But our aim is to bring it in
• 2:21
  holistically, you know, at the front end.
• 2:23
  And what's kind of what's that that value then that you're
• 2:26
  giving the end merchant you mentioned there, it could be
• 2:28
  acquiring, it could be gateway, it could be APM, it could be
• 2:31
  terminalisation. What's that value then through
• 2:34
  the merchant that's being delivered?
• 2:35
  Yeah. I mean, I think broad brush
• 2:37
  without getting too finite into it, our value sits in probably 3
• 2:40
  main areas. The first area is, you know, we
• 2:45
  solve at the front end a real challenge as to how to manage
• 2:50
  multiple downstream payment service providers without being
• 2:54
  right in slap bang in PCI scope. So we set as a front end layer,
• 2:58
  we have our own tokenization engine that directly connects
• 3:00
  them with the schemes. We can effectively without
• 3:04
  putting them more in PCI scope, keep compliance the same and
• 3:08
  have an agnostic layer there. The second thing that we do is
• 3:11
  optimization. Now this is effectively our
• 3:13
  routing engine, our ability to route traffic based on data
• 3:16
  points that we see from either the payment flow or third party
• 3:21
  dates we might get from other services and send that
• 3:23
  transaction to the best place possible.
• 3:25
  And then finally, it's reducing the technological overhead.
• 3:28
  You know, we have in excess of 30 predefined and pre built
• 3:32
  integrations that have been tried, tested and and put into
• 3:35
  use by enterprise merchants. And so if you're an enterprise
• 3:38
  customer that's effectively saying I need to integrate with
• 3:42
  PSP 1-2 and three, we can say, well, instead of doing it
• 3:46
  yourself and having this huge technological overhead and cost,
• 3:49
  we've already done it for you. And this is how it works at the
• 3:51
  front end. And these are all the other
• 3:53
  benefits that we can deliver with.
• 3:54
  It what's the operational challenges then by working with
• 3:56
  multiple PSPS? Yeah.
• 3:58
  I mean, you've obviously got the a few that that we come across
• 4:02
  when we work with with large enterprise merchants.
• 4:05
  Example one is they're not too sure how to manage the PCI scope
• 4:10
  and risk at the front end. Sometimes they're being driven
• 4:13
  by, you know, PSP tokens, sometimes they're tokenising in
• 4:16
  multiple different places and that's just creating a data
• 4:20
  challenge and also in reality potentially a cost challenge for
• 4:24
  provisioning network tokens absolutely everywhere.
• 4:25
  So compliance risk and, and, and effectively data continuity is
• 4:29
  1. The second thing is each PSP for
• 4:33
  good reason is architected in a different way.
• 4:36
  And so if they're processing with PSP 1, they'll get a
• 4:39
  response code for error one that is 1234.
• 4:43
  When it's with PSP 2, they'll get a response code for the same
• 4:45
  thing, that's 4567. Ultimately, building that logic
• 4:49
  engine is really difficult. And so from our perspective,
• 4:52
  we've done that. That's what our bread and
• 4:54
  butter. And so we try and simplify the
• 4:56
  payment flow to have a single source of truth, whilst also
• 5:00
  giving as much underlying data as possible so they're not
• 5:02
  losing out on analytics and analysis they can do downstream.
• 5:06
  I think from our perspective, one of the challenges, you know,
• 5:09
  making sure that the quality of connection is as high as humanly
• 5:12
  possible. And we know that that's been a
• 5:15
  criticism of a number of other orchestrators.
• 5:17
  And from our perspective, it's not breadth and covering the
• 5:20
  whole planet, it's effectively ensuring that the payment
• 5:23
  service providers we work with, we have very, very strong
• 5:26
  connectivity, deep integration and service as many products.
• 5:29
  As humanly possible. You made a really good point.
• 5:30
  Now there definitely is a concern of of giving your
• 5:33
  merchants too many PSPS because how do you really manage their
• 5:37
  relationships and integrations to make sure the best of what
• 5:39
  they need to be when it comes to kind of data eventually a couple
• 5:43
  of times, what does data centralisation mean to you and
• 5:47
  to bridge? Yeah.
• 5:48
  So, so from our perspective, effectively anything that comes
• 5:51
  onto our platform, we store in a very simple database that
• 5:57
  effectively allows us to extract data in a way that's usable,
• 6:01
  clean, and hopefully a single source of truth.
• 6:04
  Now, data from our perspective comes from a number of different
• 6:07
  places. So firstly, it can come from
• 6:09
  what the payment request is. It can come from third party
• 6:12
  services, things like fraud tools, 3D secure MP is, or other
• 6:16
  things that people might be augmenting data with.
• 6:18
  And then it'll come from PSP responses and underlying
• 6:21
  response codes that we get back. We'll then effectively store
• 6:25
  that in a simple layer that someone can access, and they can
• 6:27
  either do that through our portal APIs or through using our
• 6:30
  data team. But the critical thing we want
• 6:33
  to bring to our merchants is clarity.
• 6:35
  So effectively, you know which issuer has the highest
• 6:39
  acceptance by which PSP. It's not necessarily clarity you
• 6:43
  can get through doing your own analysis because you've got to
• 6:45
  deal with the nuances about response codes from multiple
• 6:47
  PSPS. Our aim is to give a simplistic
• 6:49
  view that gives you actionable data and insight, rather than
• 6:53
  just data and insight. I think the biggest piece you
• 6:55
  mentioned there and I've had it before when you've been to
• 6:57
  multiple merchants with multiple PSPS is how do you compare
• 7:00
  apples to apples, right? You get it all the time.
• 7:02
  I've got 89% acceptance factor this acquirer and 91% acceptance
• 7:06
  this way pushing through the same traffic.
• 7:08
  It sounds like you guys are going to bridge is is taking
• 7:11
  understanding why there there is.
• 7:14
  It's, it's always our aim. And, and also when we're working
• 7:17
  with merchants who really, really, really want acceptance
• 7:20
  rates to be either comparable or better between PSPS, it's never
• 7:25
  always the obvious right? And we have to follow threads
• 7:28
  that give us the reason why that might be.
• 7:31
  So you may see, for example, you know, issuer one that's a
• 7:36
  MasterCard issuer is accepted at 89% on PSP 1 and 93 on PSP 2.
• 7:43
  It's not always as simplistic as saying the PSP could do
• 7:46
  something different. It's sometimes about what you're
• 7:49
  actually sending them and how their data model is driven.
• 7:51
  So, you know, we've had it as simple as with one PSP, they
• 7:56
  needed the e-mail address. Now most people don't see that
• 7:58
  as a required field. And we just followed the thread
• 8:01
  back and went, well, this merchant's sending it and
• 8:03
  getting this acceptance rate. This isn't and getting this
• 8:06
  acceptance rate. Ultimately, we then changed that
• 8:08
  with the merchant acceptance rates went up and everyone's
• 8:11
  happy. So I think it's following
• 8:13
  threads, but also it it's using other merchants on our platform
• 8:16
  that are using those integrations to really infer why
• 8:19
  it's not optimised. I think benchmarking's key,
• 8:21
  right, what they're able to do and understanding why
• 8:23
  something's working, it's just as important as why it isn't
• 8:25
  working at times. Perfect.
• 8:27
  And and Jacob tell me a little bit more kind of is this your
• 8:29
  first time at MPE? How are you finding it?
• 8:31
  Or you've been here before I. Have been here before I've I
• 8:34
  took a two year break so I haven't been in the last two
• 8:36
  years. For me personally, it's great
• 8:38
  conference. You know, I think what I really
• 8:40
  like about MP is it brings in a, in a, in a more small field than
• 8:45
  other conferences that you may go to a lot of partners together
• 8:48
  that we work with, operate with and, and really want to form
• 8:50
  close networks with. The other thing is, I think
• 8:53
  because of that reason, it's really attractive to merchants
• 8:55
  as well. So from our perspective, a lot
• 8:58
  of customers here, but also a lot of people we'd love to work
• 9:00
  with as well. And so from my perspective,
• 9:02
  there's a conference, it's great.
• 9:04
  The the main thing is that it it seems to bring together a strong
• 9:09
  set of the payment ecosystem and serve a need for both merchants
• 9:12
  and partners. Amazing.
• 9:13
  And last question, the shelf of shame, what one thing in the
• 9:17
  payments or Fintech world really grind your gears that you love
• 9:20
  to shelf forever? Oh, that is is a good question.
• 9:27
  I mean, from our perspective, the one thing that I would like
• 9:31
  to shelf forever is probably, and it's because we don't solve
• 9:35
  for it holistically with all our merchants yet complexities of
• 9:39
  reconciliation downstream with different PSPS, you know, they
• 9:43
  all reconcile in different ways. We'd love to have a bulletproof
• 9:47
  solution for it, and we're working on it, but right now
• 9:49
  it's proving difficult because of the complexities between
• 9:51
  downstream PSPS. I couldn't agree more, Jacob.
• 9:54
  Thank you so much for your time. It's been great to have you on
• 9:56
  and best of luck for the rest of the.
• 9:57
  Event. Thanks a lot.
• 9:57
  Cheers.