Quickbooks and WooCommerce: It Was Only a Matter of Time

using quickbooks in WordPress, WordPress plugins, WordPress Quickbooks plugin,

September 28, 2017

At Zao, one of our passions is building modular tools that solve client problems, and (our favorite part) releasing them to the public.

We were tasked with integrating QuickBooks Online with WooCommerce for one of our super rad clients, Brooklyn Tweed. Specifically, Brooklyn Tweed needed to be able to create QuickBooks invoices every time a manual wholesale order is generated (sidenote: If you’re familiar with WooCommerce, you know there is no such thing as a manual wholesale order [yet], but stay tuned for a future blog post and plugin release).

Naturally, the first step was to look for a WooCommerce/QuickBooks plugin. It might surprise you, as it did me, to find that there is not much available. Sure, there are a few SAAS options available, but nothing looked quite plug and play for what our client needed and wanted.

So, the next step was to look for a WordPress QuickBooks plugin. I found what looked like a perfect fit, only to be met by the requirement for a “Cartpipe account,” which looked to be another SAAS solution. I checked it out anyway, only to be met with:

As any good developer would do, I continued the hunt for existing tools that we could commandeer for our purposes. Fortunately, Intuit has a ton of developer documentation and resources.

Note: At this point, I should warn you that we are about to talk about OAuth. Consider this your warning.

Unfortunately, they also have a ton of their old docs and deprecated information documented, so my initial google search got me on the OAuth 1.0a path. Previously, we built this tool/library for connecting to the REST API for WordPress via OAuth 1.0a, along with a UI wrapper, so I went about forking it and attempting to use the plugin’s existing OAuth 1.0a architecture for connecting to the QuickBooks developer app. This process was… not pleasant (hint: it never is!). I eventually discovered that much of the agony in this case was self-inflicted. I was _doing_it_wrong by using OAuth 1:

If your developer account has not created any apps until after July 17, 2017, all apps created by that account will use OAuth 2.0. (source)

So back to square one…or is it two? Thankfully, OAuth 2.0 is a bit simpler in application (no signature keys, sigh of relief), and Intuit provided this OAuth2 sample app. It wasn’t long before I had converted the tool to use OAuth 2.0 and updated the UI to reflect the change, where applicable.

Why do we do this?

Much like with the WP API Connect tool (and others), we prefer to build these things in a way that they can be decoupled and used across multiple projects, and most importantly (to us), open-sourced. If you’ve ever had to rip the guts of something out of an existing project and re-apply it to another one, you know the agony I’m talking about. Building things this way selfishly helps me out, because I can use the same low-level tool in many ways, but can also help the broader community.

Here are a few examples:

QuickBooks

QuickBooks Online Connect is a low-level library for making an authenticated connection to a QuickBooks Online account.
QuickBooks Online Connect UI adds a UI to that library so you can connect to your QuickBooks developer client app from your WordPress dashboard.
Zao WooCommerce QuickBooks Online Integration Uses that Connection UI and the underlying library to allow us to integrate and import QuickBooks objects into WordPress/WooCommerce (this is in progress… use at your own risk).

WordPress API

WP API Connect is a low-level library for making an authenticated connection between two WordPress instances, using the OAuth plugin.
WP API Connect UI adds a UI to that library so you can set up that connection from your WordPress dashboard.
[redacted] is a custom client plugin that allows the client to have a publication workflow on a completely separate WordPress install and selectively publish vetted/completed content to the public site. It uses the Connect plugin to make authenticated requests, and the UI plugin to establish that authenticated connection.

Twitter

TwitterWP again, is a low-level library for making authenticated requests to the Twitter API.
WDS Twitter Widget is, as expected, a widget which outputs recent tweets which relies on TwitterWP.
And DsgnWrks Twitter Importer is an automatic tweet importer built with TwitterWP used for backing up or archiving your tweets.

And the list goes on!

CMB2 is another perfect example of a modular tool that is being used all over the place and bundled into many projects (including the above QuickBooks Online Connect UI and WP API Connect UI plugins!).

Yet another (possibly overlooked) benefit to releasing your modular tools, is the continual contribution and improvement by others in the broader community. The Intuit Quickbooks PHP SDK that we worked with for this project is an open source project (and on GitHub), so we were able offer some improvements to their library with two small Pull Requests. The benefits to releasing your tools often goes both directions.

When you can put the effort in to make a tool or library available modularly, it can provide a huge head-start to your future self, and even better for many others in the community.

If you need more information for how to use this stuff, look at this example file. If you’re interested in more things Zao has released/worked on in the spirit of sharing and modular development, check out these posts:

Join the Conversation

3 Comments

Richard Buff says:

October 16, 2017 at 12:56 pm

Great article! I’d be curious to know how you were able to give the client a price for this piece of functionality since you didn’t even know if a solution existed at the start of it? Was there discovery involved in order to cover all that time spent figuring out how you’d even start working on this?

I’d also be curious to know about how many hours all that searching and tinkering took before you got on the correct path using OAuth 2.0. My nightmare is wasting days and days fooling with something only to find out it was the wrong course.

Reply
JT says:

October 16, 2017 at 1:17 pm

Thanks for commenting! As for your first questions, we intentionally scoped it and assumed we would likely be having to build from scratch, or building a solution which would take a similar amount of time/effort. The reason is that, unless we already know of a decent solution for a problem, even if we do find a great solution, there is likely going to be a fair amount of bending and twisting to fit the solution to match what the client wants. It's often possible that it will take a similar amount of time to build something from scratch as it will to implement a client's tight functional spec against an existing solution.

I would be pleasantly surprised if/when the day comes that we drastically over-estimate a project because an existing solution was so robust, but if that day comes, the price that the client is paying is still justified if you believe in the mantra of value-based pricing. I.e. it's hard to put a monetary value on having an experienced developer on your side who can thoroughly review an existing solution and come to the conclusion that it is an (almost?) exact fit for their needs, and being able to implement that solution, test it, document it, train for it, etc, etc.

If that unicorn situation occurs, I'm willing to bet the client will not end up feeling cheated when we are finished with the project.

And at the end of the day, we value our relationship with the client more than the potential windfall, so there have been situations we have credited them for the unused time towards a future project. Those situations are usually because through the process, we determined a certain bit of functionality we planned to build would no longer be necessary, or something along those lines, but the principle applies here as well.

Re: searching/tinkering and lost days — Every contract should accommodate for searching/tinkering time. Now, obviously, that time variable is extremely hard to predict, but with a proper discovery and proper functional scope, it's much easier to hone in on that estimation. In this project, most of the work i put into the Oauth 1 implementation was able to be ported over to the Oauth 2 implementation, but there was certainly some head-banging time lost when the wrong implementation was obviously not working. I can't recall ever spending days and days on a solution and having to throw it all out. I won't get into this fully (maybe a future post?!), but If you build modularly enough, much of what you write should remain interchangeable, so you can swap in the final correct solution.

Reply
Parker Mathewson says:

December 5, 2017 at 11:38 am

This article captured my exact emotions through the last few months while working on finding a solution for a new client to integrate with Quickbooks, it really is quite amazing. While I was working on other parts of a brand new website for my client, I was always doing more research at the end of the day trying to find a past solution for quickbooks, I mean, there had to be a solution out there, right? Quickbooks dominates the market share for small business accounting software, why wasn’t there a working plugin even just for the basic OAuth connection?

Then I found this article, and you guys have seemed to be a couple months ahead of me! Not only did your article give amazing information on the topic at hand, but gave great insight to so many tools that I haven’t been using while really learning WordPress plugin development. Coming from a Software Engineering background, mostly from a large company where everything was proprietary, I have been learning so much from reading brilliant people’s code and articles, trying to absorb as much information as I can.

While I have used similar tools, and I have seen composer around, this article has brought me to learn how to actually use composer, and incorporate it into how I am composing my plugin projects. And while learning how composer works, I read an article saying “you’re not going to directly download all the dependencies”…. well I was…. and have now learned the error of my ways.

Just some thought for introspection, why do you think it is that the passed plugins are no longer available and no one has really put out anything remotely similar? WooCommerce has a Xero Accounting integration (a less used accounting software) listed under their extensions and plugins, and they had one for Quickbooks Online as recently as 2012, but it was taken down. While discussing with my client, the reason we decided to go with Quickbooks is that Intuit is a huge company that is not going anywhere anytime soon, to where a lot of the small business accounting softwares (e.g. Xero) are a bit more risky in terms of long term viability. Do you think this is just developers dropping projects, or is there something more sinister that we should be aware of while continuing down the self integration path?

Thank you, JT, for putting this great code out there, and for having great articles for me to dive into!

Reply