Developers want better user experiences, not to become payment experts

Developers don’t want payments, and they don’t want Elasticsearch. They want a better user experience for their users. They want the experience we have all come to expect from Uber (payments) and Google (Elasticsearch).

When these moments live outside your app, it makes your software seem old. Users are left wondering: “Why do I need to leave this app to make payments when Airbnb, DoorDash, and all the others allow it? Junk!”

Let’s unpack a common scenario.

You’re the lead developer at a software company solving problems for doggy daycares. You’ve spent many hours building a complex integration with a payment processing platform. The integration allows your customer (the doggy daycare owner) to handle online and in-person transactions directly through their app. It’s also how the dog caregivers get paid. As daycare businesses grow, owners receives frequent requests from their customers and caregivers—not to mention their own ideas for improvements they’d like to see in your platform.

Everyone wants optionality for how they send and receive money: ACH, Same Day ACH, RTP, push-to-debit, pre-paid cards, and a host of other third-party integrations. As the lead developer, you may think these requests seem trivial. But at this point, it doesn’t even matter. You have no say in the roadmap of your legacy payment processor.

Even if you decided to bring the payments experience in-house, you would now be spending valuable time and energy trying to orchestrate third-party payments versus executing on your mission to make pet daycare simpler for operators and pet owners. What does it even mean to bring payments in-house? How do you scope the effort? Should you get on the phone with technical resources from your company’s bank? Search for payment APIs? (If you are building anything related to payments, join thousands of developers and product builders in our Slack community.)

It’s daunting to know where to begin, but it shouldn’t be.

At Moov, we believe developers don’t want to spend their time learning fintech terms. You want to delight your customers with new features. Ultimately, these product experiences should allow your business to unlock new value streams and keep users in your platform. You shouldn’t have to spend months figuring out how to build payment technology, manage risk and compliance, and become a payments guru. That’s not the business you set out to create.

You want to stay focused on adding value inside your app. And that’s why Moov exists.

Our veteran team knows the US banking system and deeply understands payment infrastructure. It’s a maze of abstractions and integrations, full of acquisitions, shallow APIs, and more complex than you can imagine.

We are here to change that.

What we are building is bigger than banking-as-a-service. We’re heading in the opposite direction by connecting people to payment networks. We’re making it easy for developers to accept, store, and disburse money. Period. Everything underneath is on us, from secure data collection to utilizing multiple payment methods with one API and leveraging new ways to monetize your product.

We’re on a mission to help developers keep doing what they’re best at, changing the world with new and innovative software experiences, not becoming payment experts.

Twitter Tweet this

Moov started as an open source project for Nacha file creation and validation for ACH. We wanted to make it easier for developers to build with low-level banking protocols. Our commitment to open source continues, but this is only one aspect of what we’re building.

As we continue to bring beta customers live, we’re also hosting a fintech developer conference, growing the team, and doing everything we can to enable you to unlock fantastic product experiences. We are a payment platform for platform builders, and we can’t wait to show it to you.

Intrigued? Subscribe to our newsletter or follow us on Twitter. We’ve only just begun our journey, and we hope you’ll join us in whatever way makes sense for you.