A few months ago I wrote a plugin that connects Spee-Dee Delivery, a shipping services for the upper midwest, and WooCommerce. The plugin is going through the audit process right now and should be launched shortly. While the whole process has taken a few months in terms of time writing code the project has only taken ~40 hours. About 20 of which have been doing QA testing to make sure it's as intuitive as possible and doesn't need to be done unless you're planning on selling your plugin.
I'm going to go over the whole process of creating a shipping method: what you have to do and how much time it's going to take you.
1. Assembling the Shipping API Skeleton
If you've done plugin development before you know there's a lot of organization that goes into this. You usually have to include a bunch of files, set up dependencies, and hook into the existing framework. Luckily WooCommerce makes this quite easy because they have a really handy Shipping API Guide.
All in all it's probably around 100 lines of code once you're done. The best part is that it's really easy code usually just replacing the place holder name with your plugin name.
2. Adding in the Shipping Method Costs
This is the real meat of the work. You already have the skeleton and now you need to graft the muscles to make the bones move. This is the part where instead of returning a dummy value of $10 for every request you actually do some calculations and display an accurate number.
If you're only doing some calculations in your code this shouldn't be too bad. Maybe you're charging $1 for the first item and a flat rate of $10 for items 2-50 and then an additional fee after that. Anything like that should be as simple as writing a couple lines of code.
Interacting with a 3rd Party Service
If you're interacting with another 3rd party service like UPS, USPS, FedEx, or something of that nature you hopefully have access to a PHP wrapper for their API. If so something like this shouldn't be too bad. It will definitely take a couple hours to learn the ins and outs of the library but one you get that fully functional a couple calls and you're done.
If you don't have any sort of wrapper for this service this will probably take a while – and by probably I mean definitely. Writing all of those XML calls is tedious and there's going to be a fair bit of trouble shooting to get the library working correctly. If a client is asking you for a quote for one of these services you should respond with forever in terms of the timeline. This is one of those things every developer thinks will be a sinch and it always takes longer than expected.
Packing Items into Boxes
There is one other big piece of functionality you have to write. A very common feature is to pack items into boxes. There are very few businesses out there that regularly ship items individually. If you want to add in box packing you can certainly add in the WooThemes box packer (included in our own shipping extensions like UPS, USPS, FedEx, etc) and write extra code for that but then you'll also have to add in extra fields in the admin panel so users can specify their box sizes.
3. Dummy-proofing the Whole Plugin
By now you have a fully working shipping method. It works great for all of your test products and here's where the tricky part comes in. You need to imagine all the ways your users will break your project. I promise you if you think you thought of all them you're wrong. Users always find ways to break your programming.
One of my suggestions for writing software like this is to release a private beta. Then you can cover most of these issues with users and fix them before they're released to the general public.
- Do the products have a weight set?
- Do the products have dimensions set? Do they have to?
- What happens if your service requires a US zip code and the store is in Canada?
- Do you require a specific currency?
- Can products weight less than a pound?
- What some products fit into boxes and others don't fit into a single box?
- Are you converting units (ex. if the customer selects to use feet for dimensions instead of inches)?
- What happens if the API is down?
- How do you display all of these errors to alert the admin but not the average customer?
As you can imagine there's a lot of time spent here and anything not caught here is usually what makes it into a bug fix branch.
With a good PHP library for a 3rd party service this might not be too bad. Especially if you look at the existing shipping methods. If you don't have a good library and you are interacting with another service be prepared to spend a lot of time on this. And no matter what be prepared to spend time QAing your project. If you're doing this for a client make sure you build in time to fix any future bugs because they will pop up – guaranteed.