Developer Spotlight: Payable Forms
Bringing the power of payments to small business tools
Welcome to our Developer Spotlight series, where we highlight developers building on the Square platform. In this installment we speak with Ryan May, the founder and Lead Developer at Payable Forms.
He previously worked as an engineer helping big brands all over the world integrate payments into their business. Since launching their app, Payable Forms has had 200,000 downloads and helps move 6-10 million dollars per month in payments. We asked Ryan about what kinds of problems they are solving for sellers, what led him to choose Square, and about his experience building Afterpay and Cash App Pay using Web Payments SDK for his clients.
Come along to learn how Payable Forms measures the health of their payment integration, why they chose Square, and what other technologies they use to build out their business.
Ryan, could you tell us more about what business solutions Payable Forms provides to its clients?
Payable Forms is helping people tiptoe into technology through low-code payment tooling. We noticed that small businesses who wanted to build an automation process were supported by these really geeky tools that require you to almost be a quasi-developer. Our goal was to make drag and drop tools for everyday people and help them connect business processes to payments. We started with our first app Payable Forms using Google Suite, and have since had 200,000 downloads of the app.
We’ve found this unique sweet spot where our clients can use our app to set up a form, add questions with various money amounts, set up subscriptions, or add automations where digital goods are delivered after a payment. We’ve been really excited to see how we can bring the power of payments to the tools people are using to run their businesses.
You recently made Square your preferred payment partner. As a developer, what do you look for when choosing to build with a payment platform?
One thing that is important to us is the ability to onboard a new seller really quickly and Square can do that efficiently in real-time and in all the key geographies we operate in — plus you support the key demographics we cater to which are micro and SMB sellers.
Secondly, our whole business is based on the app fee model, our clients are small and may not want to pay an upfront fee, it’s more attractive to them to just pay a fee when they are getting paid, and with some of these businesses being seasonal, they don’t have to worry about only getting value for our support for the few months they are operational. I can easily add an app fee with Square. Which is also supported across alternative methods like Cash App and Afterpay.
But I’d say the most important thing Square does is client-side encryption. I get to sleep well at night because I’m not touching credit card information. Amazingly, a lot of payment vendors don’t do client-side encryption, these vendors ask you to take raw credit card data and send it to their API for authorization, I have 50,000 small businesses who have installed a payment method and I’m not touching credit card data for any of them, I wouldn’t do it! I don’t ever want to integrate that way.
"We are helping people tiptoe into technology through low-code payment tooling"
You’ve integrated the power of Square’s payment platform into Payable Forms using the Web Payments SDK. Could you share what your developer experience has been like?
I previously worked as an engineer helping enterprise companies integrate payments with Paypal, Braintree, and Adyen. I'm impressed by the Web Payment SDK and I honestly think it has a ton of potential in enterprise applications — it seems reliable. The JavaScript on Web Payments SDK is clean and the UI is customizable. I really like how it dynamically figures out the card locale and puts ZIP code or postal code, that takes a ton of work off the developer to not have to build it in every time. Fundamentally it's really good architecture and the uptime is good as well.
Your developer documentation is by far the best documentation in payments — the way you do interactive: it can pull samples from your sample account, it can look at merchants, it can look at currencies, I can send out requests and get responses right inside the developer docs. Plus all of your APIs are consistent from Customer to Rest to Subscriptions, it’s all clean and really really good.
You also recently launched Afterpay and Cash App Pay as payment methods for your clients, why did you decide to integrate with these payment methods?
We always want to offer as many payment methods to our clients as our payment service provider offers and we were getting a lot of requests for Cash App Pay because there is a large group of our sellers who are looking for a way to automate P2P (person-to-person) payments. Essentially what they want is a Cash App to Cash App API but because that doesn’t exist we are giving them a path to do what they are looking for by having them sign up for Square to be able to accept Cash App, and in the back end are supporting this via the Web Payment SDK. We always want to find a way to say yes to the solutions our clients need.
For Afterpay we found that micro-sellers were trying to find ways to offer financing options for the services or products they provide but were using a manual and high-risk process, but with Afterpay they can instead get all their money upfront through one transaction ID at the point of purchase and still give their customers time to pay.
Both these payment methods offer value to our micro-sellers and SMB customer base and both allow for discovery and new product features. When we compared the minimal engineering lift to implement these payment methods versus the product feature benefits we got to market to our customers, it was well worth it. Plus we had already implemented Apple Pay and Google Pay and the way you’ve implemented your alternative methods is very similar to these digital wallets.
"I’m impressed by the Web Payment SDK, I’ve always been at Paypal, Braintree, and Adyen doing more enterprise payment integrations and I honestly think it has a ton of potential in enterprise applications — it seems reliable … Fundamentally it's really good architecture and the uptime is good as well."
How do you measure the health or quality of your integrations?
We have a few things that run. We are logging API request time speed and status codes that come back, and JavaScript monitoring any client errors that may be happening on the client-side. The first and most important thing is successful experiences or successful page loads and the speed of the interactions. Square is the fastest and most reliable with speed, we’ve had such few failures with Square in comparison to another solution we have been using where their APIs are constantly going down and the JavaScript for JavaScript SDK is constantly messing up. I’ve rarely even seen a hiccup with customer experience and uptime on Square, whereas our other payment integration goes down every week for about 45 minutes to an hour.
We also measure the ease of experience for our customers' clients. We don’t have an issue with clients calling us about payments going through with Square, you’re doing KYC and underwriting upfront so you’re letting people process cards. And we get correct decline codes back so we can help our customers when we see a decline code, for example when a payment is not going through because of insufficient funds. It’s really important to ensure our sellers can get paid by their clients when they go live.
What other technologies and Square APIs are you using to build your app?
Half the app is Google Apps Script and we call our own web server, which is also a web-hosted checkout page that is written in PHP — I’m an old-school developer that way. We used a lot of different Square endpoints, we used Catalogs and Invoices to set up Subscriptions, and we used Customers to add customer data to customer fields. We also enjoyed Orders API which is good for shipping fulfillment and closing orders, plus it’s super flexible.
We know the importance of learning and support for a developer, what are your go-to learning/support resources at Square?
Your Slack channel is really good, sometimes when I’m up at 2 a.m. or 3 a.m. and I’ll go to the Square Slack channel and I can get a custom response from someone really knowledgeable in three hours, plus I can also search for decades and find past answers that have been great in helping me resolve issues.
We want to give a big thanks to Ryan May from Payable Forms for taking the time to talk with us about his company and experience building with Square.
Watch our Sandbox 101 video to learn how you can get started with Web Payments SDK in your own application. You can also check out our developer documentation. And as always, please share your feedback on our community Slack channel or Square Developer Forums. If you want to keep up to date with the rest of our content, be sure to follow this blog and our Twitter account.
Authored By
- Ryan, could you tell us more about what business solutions Payable Forms provides to its clients?
- You recently made Square your preferred payment partner. As a developer, what do you look for when choosing to build with a payment platform?
- You’ve integrated the power of Square’s payment platform into Payable Forms using the Web Payments SDK. Could you share what your developer experience has been like?
- You also recently launched Afterpay and Cash App Pay as payment methods for your clients, why did you decide to integrate with these payment methods?
- How do you measure the health or quality of your integrations?
- What other technologies and Square APIs are you using to build your app?
- We know the importance of learning and support for a developer, what are your go-to learning/support resources at Square?