Bridging the Stream of SMB Payments

When it comes to payment card processing, small businesses are big business. Beanstream Internet Commerce, which Digital River acquired in 2013, is an online payment gateway and merchant account provider that is focused on providing solutions for the increasingly vital SMB market. PYMNTS recently caught up with Brent Owens, Developer Liaison at Beanstream, at his home base in Victoria, BC, to learn more about the company, its developer platform, and its ongoing plan to positively disrupt payments at the point of sale.

Beanstream has been around since 2000, and Digital River picked it up in 2013. If you would, introduce us to Beanstream – give us your elevator pitch of the company.

BO: Digital River does a whole lot of payments work, from commerce, to email marketing, to eCommerce payments, and Beanstream is really the small- to medium-sized business portion of that.

We’re based in Canada, and that’s where we grew really strong. As you said, we’ve been growing since the early 2000s; we’re processing…more than $24 billion a year in payments. So we’re quite strong, here, and we’re starting to reach out a little bit more into the U.S., now. We have a big U.S. launch coming up this year— We’re already in the U.S., but we’re kind of going with a larger launch, coming out soon.

We’re quite well established; some of the banks here in Canada, such as Toronto-Dominion and First Data Canada, are actually using us as their white label partner. So when you’re using TD Online, you’re actually using Beanstream. That’s really helped catapult us into the merchant arena here. It’s been working out quite well.

It’s a smaller-sized company; we don’t have hundreds of people at Beanstream. We’re actually at just under 60 people. We kind of operate almost as a lean startup, in a sense: we’re very agile, our development process has quick turnaround, and there’s a lot of great people here, too. It’s a really fun place to work.

Tell us a little bit about your developer portal. What tools are you giving developers and entrepreneurs to use? What’s in and out of bounds with regard to that, and why?

BO:  The portal is really a place for developers to congregate and use our system. Traditionally, with payments – especially going back into the 2000s – they have been targeted more at the merchant. But often what we’re seeing now is that the merchant is actually the software developer. Or where the software developer is working for a company, and the company says, “We have a website, we’re selling these products; we need to take payments” – they’ll leave it up to the developer to find the tools to actually take the payments.

The developer portal is a way to reach out to those developers, speak the languages that they speak – such as programming languages – and really get the message out to them to say, “We’ve got the good tools here that you need. We provide the solutions that you need – from a developer standpoint but also from a merchant standpoint.” And that’s what the developer portal is focusing on.

We have several APIs for our payment systems. Since we’ve been around for so long, now, we’ve gotten different flavors of the APIs: we’ve got our old SOAP API, we’ve got our kind of middle-aged – “middle-aged” is about 4 years old – Process Trans API, and then we’ve got our newer RESTful API.

But on top of that, what we realized is that we really need to build some more tools around it. APIs are great – what they allow you to do is connect to the payments services from any kind of device, using any programming language, wherever you are. They’re really great for that. But there’s still a little bit of work that the developer has to do on their end. And it’s a lot of the work that every developer is going to have to do – such as creating connections to the servers, checking for errors, and all that sort of thing.

The tools we’re building are software development kits, or SDKs. They help bootstrap the connections for the developers, handle those exceptions, and just make it a little bit easier for them to connect to our payments services.

So that’s a lot of what we’ve been focusing on in the developer portal: building out that suite of tools just to make development time a lot easier and a lot quicker. Because, in the end, when a company is building its website – say they’re a startup – and they’ve got this great idea, they don’t want to really focus on taking payments. That’s just something that they have to do – they want to…get it done, get it over with – and we want to make sure it’s a nice, quick-and-easy process for them.

Talking a little more about developers…when you look at what they are bringing to the table today, how much of what they’re doing can be translated into payment innovation, and how much is just a variation of existing payments methods?

BO: I’m seeing a lot more of software-as-a-service, now. These companies…maybe they started off writing software for a specific vertical, and then they kind of found a niche, saying, “Hey, we see a real need here to sell our software as a service for other companies.”

This happens in gift cards. You’re starting to see gift card companies that almost white-label themselves for other gift card companies, or other gift card services. So they focus on their one vertical, their one area, and they do it really, really well. Which is great. If you need that gift card for your company, then you can find the company that’s doing it incredibly well, leverage that service for a very affordable cost – much cheaper than building it in-house – and then you have some experts there who have been doing it for years, and know how do it. I’m seeing a lot of software developers move to that model.

And that’s also pushing a lot of the data for those merchants into the cloud. A lot of their transaction history or inventory is stored in different services: on the Web, on the cloud – the actual physical cloud, too, such as Amazon Web Services, or Zer, or Heroku, things like that. A lot of companies are putting their software on there, as well as their data, and it’s really spread out – which is great, because then there’s no single point of failure and you can leverage whatever services are out there. I’m seeing a lot of apps start to go that way, along with other services.

Based on your experience, what do you think are the Top 3 most creative examples of emerging payments at the point of sale?

BO: I love NFC. Touch payments are fantastic. I love to just touch my credit card…and go, then I’m done. That’s great. And I’m really excited for biometric services such as Apple Pay, and just being able to NFC-touch and pay, and be done with it. That, I really like.

I also like the idea of being able to order ahead, and show up at the retail outlet or restaurant, and just have everything ready for me. It saves the consumer tons of time – while you’re driving to the place, they can get the order ready for you.

I like any apps that are starting to branch out into this more omnichannel market. Instead of just brick-and-mortar versus eCommerce, you’re getting, say, the Tesla Motors model, where you go to the showroom, and then you go online and order the car – which is a totally different business model. That’s one of the new omnichannel models.

But then also, the order-ahead model is: you go to Amazon, you order the product, and maybe you then go to the physical retail store and pick it up. A good example would be pizza restaurants, where you can order online, show up, and pick it up. That’s a great model. And a lot of apps are starting to move in that direction. It provides convenience for everyone; it’s slick, it’s easy to do; it’s secure, it’s safe, and it’s hassle-free.

You take a look at Uber – it’s beautiful. It’s so easy to use. And they’re really disrupting the market, too. You can see how upset companies are – especially taxi companies. There are legal battles everywhere, because it’s so disruptive. I wish we had Uber in Vancouver and Victoria, here – that would be wonderful.

One other payments technology at the point of sale that I like… I’ve been talking with a fellow based in Victoria. We’re a bit of a craft brewery town, and he loves craft beer. And he’s been talking with breweries and finding out that a lot of them…lose their kegs. They have a hard time keeping track of them. It happens. They’re over $100 per keg or so; and often there’s a damage deposit put down – but still they lose them, they misplace them…and then they don’t know necessarily how old the product is inside the kegs.

What he’s done is written an app for them that will allow them to track all of that. What he wants to do is integrate it into their actual point-of-sale systems, so when a customer comes by and wants to rent a keg of beer, then it’s automatically tracked for them. They know what keg, how old the keg is, how old the product in the keg is. It’s just a very specific vertical that this point-of-sale-software is for: it’s for micro-craft breweries.

I think…we’re going to see a lot more of that, where it’s very specific. So instead of just for, say, a restaurant, you might have a specific type of restaurant – like a fast food restaurant app. Or a food truck app, that sort of thing.

What can we expect from Beanstream in the near future, and – if you can disclose it – what are you working on?

BO: We’re working on something pretty exciting. We’re quite well versed in the eCommerce, or card-not-present, payments platform. We’ve done the card-swiping, card-present device, sort of similar to Square, where you swipe your card at a vendor’s booth and take payments that way.

And in Canada, we’ve had EMV for a while, now. But it’s starting to come out into the U.S. this year, so merchants are really going to have to jump on board for that.

So we saw that ahead of time and decided, “OK – there’s a real opportunity here not to just provide another device for people, but also to take advantage of the changing point-of-sale service. Moving to apps, moving to the cloud, and moving to quicker…more affordable options for merchants.”

What we’ve developed is our Sprout POS service. “Sprout,” for “Beanstream.”

It’s kind of two parts. The first part we have right now is a payment device, built by Ingenico. It’s a chip-and-PIN, EMV, NFC device. A small payment pad…a little bigger than an iPhone. And we’ve built an SDK that allows apps to talk to that device. So instead of building our whole payment interface onto the app, what we’ve done is built a sample one, but we’re providing developers with the tools to integrate into it.

It is a lot different from what some of our competitors are doing. They’re saying, “Hey, use this service right here; if you’re using this hardware, you have to use our software.” What we’re saying is, “No, no – you can use our SDK and then you can just build payments into your app; you can build point of sale into your apps very easily.”

We’re working with other, larger companies that have established payment systems for, say, restaurants or other retailers. And we’re saying, “If you use this device here, you can tie into it with your software and you don’t have to rewrite your entire software suite. Your app can stay the same, but you can now take payments in person.” So that part is really exciting.

That’s the first phase of our Sprout POS system, and that’s entering into closed data right now. We’ve got a couple of merchants live with it, and…within the first few weeks or so, we’ve had about 300 merchants sign up for the closed data – and that’s just in Victoria, around here.

It’s really shown us that merchants want a more affordable way to take payments without a clunky cash register. They all have tablets, they all have apps and iPhones or Android devices, so they know how to use them. Apps are pretty cheap; you’re looking at $5 to $50 or $100 in…monthly fees for some of these retail apps, which is a lot cheaper than some of the other services out there. And the Sprout POS payment terminal has…a rental fee of…less than $20 a month. So it’s for any kind of merchant who wants to use it.

The other part we have…to complement that is…what we’re calling “offers in the cloud.” It’s a mechanism that we’re using to allow apps to communicate with each other through Sprout.

Instead of apps being their own little silos, they will be able to communicate some of the information around, as long as it’s authorized by the merchant. The merchant will be able to, say, get a loyalty card app…and that loyalty card app will actually be able to reward the consumer with gift cards through a different gift card app. So these apps will be separate, but they can actually work together through this system, and without us bogging them down. We’re giving them the tools so that the apps can interact with each other: what the data is, what the merchant is doing, and what the consumer is doing.

I think we’re going to see some amazing ideas come out of that. What those specific implementations are, I don’t know yet; we’re kind of leaving it up to the developers…to dream up the cool ideas. But I think it’s going to be a really exciting next year or two.

Brent Owens

Developer Liaison at Beanstream, A Digital River Company 

Brent Owens has a decade of experience as a software engineer in mapping, emergency management systems, video gaming and to payments. As a contributor and core developer to several open source projects he has his finger on the pulse of the developer community. He works to ensure developers have the right tools they need and the right solutions available to bring their projects to fruition.