I’m not going to pretend that I’m sorry
Let’s just skip the whole part where I go “Oh man has it been X long since the last post? Sorry guys! I’m so quirky and unpredictable it’s not my fault!” like I’m some kind of D-List Twitch streamer with 27 followers. Frankly I’d be much more popular if I was a D-List Twitch streamer with 27 followers instead of an F-List LinkedIn personality with 1200 bots and 6 real followers who read just for the Kaseya jokes. But I digress.
Everything about this integration is excessive
And while I don’t normally condone that, it’s different when I do it. Because reasons. Or as my three year old loves to say “because yeah, dad.” It’s a stellar argument honestly, and I would defy you to come up with a worthy counterargument to logic like that. (Fun fact: “porque sí” (because yes/just because) is a 100% valid thing to say in Spanish, which is the primary language in the country we live in. I’m having a hell of a time trying to explain to my 3-going-on-30-year-old that “because yeah” doesn’t really work the same in English.)
Anyways, excessive and stuff, yeah. So despite being a web application developer I actually hate traditional web design. As you can tell by my circa-1998 Geocities-esque template on my shitty WordPress blog, graphic design is not in fact my passion.
This presents a problem when trying to automate or self service things that annoy me when they cross over into web design. The prime example of this is our professional services page where people book HaloPSA or other consulting time with me. I’ve always been a big believer in “I will absolutely not make you a bespoke quote, SOW, contract, NDA, invoice, payment intent after I already met with you for up to THIRTY PRECIOUS MINUTES OF MY TIME” which leads me to run my inbound pipeline a bit different from other consultants. Me (or my assistant) not having to do shit is the name of the game here. It would also look pretty shitty if a self proclaimed automation expert did all that junk by hand.
In light of all that, my solution short term years ago was to stand up WooCommerce in our WordPress instance, hook it up to stripe for payments, and then set up a webhook from WooCommerce to an Azure Runbook to register the orders/clients/invoices into Halo. That was my zero-web-design solution and it worked pretty well. Well, demand skyrocketed and here we are several years later with that original system still in place. Stripe doesn’t make it easy to pass on the fees and we’re getting absolutely robbed blind. Expecting me to do *math* to calculate those fees and add them on during checkout? Get the actual fuck out of here, dude. Why would I do the easy thing when I can build the fucking space shuttle instead?
Uh oh.
Uh oh is fuckin’ right.
I’m friendly with Baxter Lanius, the CEO of Alternative Payments. A few weeks back, Baxter and his marketing team reached out and asked if I’d do a webinar for their office hours podcast. We eventually settled on doing something around automation with their new API. And because I’m an asshole, I stupidly offered to whip something up within a couple weeks that we could talk about on the show that would revolve around modernizing my WooCommerce + Stripe setup to use AlternativePayments.io to process payments.
This all sounded great coming out of my own mouth at the time but a few hours later it dawned on me that I’d have to do a lot of annoying re-engineering to make this work. I was pissed at myself because I knew I was going to suffer for it, but more importantly I was pissed off at Baxter for being such a nice guy and trying to include me in stuff. Baxter is unironically one of the coolest guys you’ll ever meet and AlternativePayments.io is the bees knees. He’s not even paying me to say that.
To be clear, he should be paying me to say that, but he’s not. Although I’m told the car “is in the mail.” I’m hopeful it’s a check for a car and not a hotwheels but I think we all know how that’s going to go.
This seems niche as fuck.
Listen, I’m not under any illusion that thousands of MSPs are running WooCommerce stores that need HaloPSA and AlternativePayments.io integration. This is probably one of the nichest (is that a word?) integrations I’ve built. But here’s why it matters:
This is a proof of concept for how flexible HaloPSA actually is when you combine it with runbooks and external APIs. Once you understand the pattern—webhook triggers runbook, runbook orchestrates API calls, data flows back into Halo—you can apply this to anything.
Replace “WooCommerce” with any system that can fire webhooks. Replace “Alternative Payments” with any payment processor or service that has an API or that integrates with Halo or your accounting package. The framework is the same. Halo runbooks are fucking powerful when you stop thinking of them as just “workflows that run on a schedule or trigger” and start thinking of them as “API orchestration engines that can do basically anything.”
Integration Components
This integration has three main pieces that all talk to each other:
- A custom WooCommerce payment gateway plugin (WordPress/PHP) – This does three things:
- Sets up an authenticated API endpoint that Halo can write back the payment URL to when it is available
- Allows configuration of the display behavior of the payment method in WooCommerce checkout
- Provides a waiting/payment page that holds the users browser session waiting for the payment URL and eventually redirects them to Alternative Payments
- A HaloPSA Custom Integration Runbook (the brain of the operation)
- HaloPSA Custom Integration + Methods (extending base runbook functionality)
The sequence of events happens like this:
- When a customer places an order in WooCommerce, the plugin fires a webhook to my HaloPSA runbook.The user is redirected to a waiting screen that shows their payment being set up and each step happening. It continuously polls in the background checking if the payment URL has been written back to the order in WooCommerce’s database yet.
- The runbook checks for duplicates and then creates the Client (with the main contact, billing plan, prepay block hour time, and site information with domain all set)
- The runbook creates an invoice in HaloPSA for whatever they bought (pro services block hours or a HaloPSA guided implementation)
- Waits for the invoice to sync to Alternative Payments (which happens via webhook from Halo) and for AP to write the third party payment link onto the invoice in Halo
- Detects the third party payment link being available and sends that link back to a custom API endpoint in WooCommerce running on our WordPress site.
- The payment holding page detects the URL being available and redirects the customer to it to pay.
- Customer pays, Alternative Payments processes it (while passing on fees), and everything syncs back to Halo natively.
No Stripe fees. No manual reconciliation. No calculating payment processor cuts. Just a cold, calculating, unfeeling automation pipeline that does exactly what it’s supposed to do.
But that doesn’t use the Alternative Payments API, you phony
You’re right – it does not. In my defense I did, in fact, attempt to use their API to do this whole thing with a one-off payment intent that their API supports. Then I realized that was fucking stupid because why interfere with the Halo <> Xero <> AP sync cycle to artificially inject payment intents? It’s not necessary in this case. Halo’s integration with AP allowed me to reduce complexity and in automation that is a win.
I did scaffold the custom integration methods for the AP API inside Halo and may revisit this in the future to do it all via API, but there’s no compelling reason for me to add the complexity at this time.
Prerequisites
Before you dive into this, you’ll need:
- WordPress with WooCommerce installed and products configured (obviously)
- HaloPSA instance (or an Azure Automation Runbook to bridge to your CRM)
- Alternative Payments account (get one at alternativepayments.io—tell them Ceej sent you, maybe Baxter will finally buy me that car)
- Basic understanding of PHP or a good friend like Claude/ChatGPT for the WooCommerce plugin modifications
- Coffee or your preferred stimulant because we’re about to get weird with it
The WooCommerce plugin: Hijacking the payment gateway
The first piece is a custom WooCommerce payment gateway plugin. WooCommerce has a pretty solid framework for building payment gateways, so we’re not reinventing the wheel here—just bending it to our purposes.
The plugin does a few key things:
- Registers a new payment method in WooCommerce called “Alternative Payments”
- Displays the payment option at checkout with your custom branding and configuration
- Sets up an Authenticated API Endpoint that Halo will use to write back the payment URL when it’s available
- Handles the wait and redirect to the Alternative Payments payment page
The beauty of this approach is that WooCommerce handles all the cart logic, tax calculations, and order management. We’re just intercepting at the payment stage to route everything through our custom workflow.
The button below will take you to my Github to download the plugin. Follow the instructions there to install it, I won’t cover them here.
Once you’ve got the plugin installed in WordPress you’re presented with a new option under WooCommerce -> Payments:
The Manage screen of the payment provider will allow you to configure how this payment option appears on the WooCommerce Checkout:
Once you’ve gotten that configured the way you want, click “External Payment API” on the left bar under the WooCommerce header. This is where we’ll configure the rest of the integration on the WordPress side. This area also contains additional tools that can be used to troubleshoot or repair orders.
This component contains a few things:
- The API key – generate a secure API key and paste it here, then click Save Changes. This API key will need to be pasted into the Custom Integration method you’ll import in the next step so Halo can authenticate its API calls back to WordPress/WooCommerce.
- Test Database Access – If you ever find yourself troubleshooting an order and you don’t know if the POST made it from Halo back to WooCommerce, put the WooCommerce order ID in this field and click Test DB Access. This will indicate whether or not the payment URL was returned by Halo. This is not usually needed, it’s a troubleshooting tool just in case.
- Manually Set Payment URL – If you find yourself in a situation where something failed in Halo (extremely rare unless your shits all fucked), you can manually override the Order in WooCommerce and set the Payment URL too. Put the WooCommerce Order ID in the Order ID field, and the AlternativePayments (or any other processor) payment link in the Payment URL box and click Set Payment URL. Any customers waiting on the order page or visiting it after this point will be automatically redirected to the payment URL you set.
- API Endpoint – This shows you the absolute API endpoint URLs for the custom integration in WooCommerce. The set-payment-url endpoint is the one we use and that is included in the custom integration method collection in the next step. The payment-callback URL is compatibility for other payment processors as this integration is vendor agnostic. You will need to update this URL in the custom integration method in the next step.
- Test with cURL – This is the curl snippet conveniently presented to you to copy/paste into a terminal if you want to test posting to the API yourself.
The HaloPSA Custom Integration Methods
Next up you need to load the following custom integrations into your HaloPSA instance. This is done by going to Configuration -> Custom Integrations -> Custom Integrations again (ugh) -> Create a new Integration and call it anything you’d like.
These methods provide the Halo runbook the instructions on how to return data back to WooCommerce. They should be loaded in before the custom integration runbook itself.
The first Custom Integration is the WooCommerce Payment API which contains the API method for posting the payment URL back to WooCommerce to allow our paying user to be redirected. After configuring the WooCommerce plugin in WordPress and configuring an API secret, you’ll need to update that API key in this custom integration also.
The second is my Halo API for Automation collection of methods. These are extensible methods to call the Halo API from a runbook (using an API application in Halo you set up and then configure with your URL/clientid/secret). The reason I use these methods is that they allow flexible query parameters and return data in a structured and easy to digest way.
The button below will take you to download the Custom Integration Methods. Follow the instructions on the Github README.md to import and configure the custom integration methods, I will not cover that here.
The Crown Jewel: Halo Custom Integration Runbook
Now for the sauce. The runbook is where all the orchestration happens. This runbook gets imported to HaloPSA and provides a URL to start it from via webhook.
When the webhook from WooCommerce arrives, the runbook:
- Parses the incoming order data from the webhook payload
- Authenticates with the HaloPSA API using OAuth
- Creates a client record in Halo (if it doesn’t already exist) and sets all the relevant information – prepay hours, billing template, main contact, site domain for email, etc. This is easily updated to do other things too.
- Creates an invoice in HaloPSA with the order details. You probably want to change the product codes and descriptions if you’re using this to sell other kinds of products, the included configuration is an example.
- Waits for the Alternative Payments API to generate a payment link for that invoice and write it back to the invoice in HaloPSA
- Returns the payment URL back to WooCommerce
- Logs everything for debugging because shit breaks and you’ll thank yourself later
The button below will take you to Github to download the Custom Integration Runbook. Follow the instructions on Github to import and configure it.
Configure WooCommerce Webhook to HaloPSA
In WooCommerce, we need to configure a webhook to fire on order creation to the URL of our HaloPSA Custom Integration Runbook. This webhook is how Halo knows to start the runbook processing.
In WooCommerce/WordPress go to WooCommerce Settings -> Advanced -> Webhooks and add a new webhook. Set the status to ‘Active’, set the URL to the Halo Runbook URL that is generated automatically on import of the runbook, and set your Topic to ‘Order Created.’ The Secret field is not used as Halo is not compatible with the authentication schema WooCommerce uses, but you *do* have to populate something into that Secret field for WooCommerce to allow you to save.
The Final Result
Fuck yeah. This isn’t the most practical or widely appealing integration I’ve ever built, but it is one of the coolest simply because there’s so much going on.
Why this matters beyond just e-commerce
I know what you’re thinking: “Ceej, I don’t run a fucking WooCommerce store, why should I care about this?”
Fair assessment. Here’s why you should care:
This pattern works for literally any webhook-driven integration you can imagine.
Replace WooCommerce with:
- A contact form submission that creates a lead in Halo
- A monitoring alert that creates a ticket
- A Slack command that triggers a workflow
- A Teams message that kicks off a runbook
- A form submission from your website that creates a quote
- An approval workflow that updates financial data
Replace Alternative Payments with:
- Stripe (if you hate your profit margins and yourself)
- Square
- Any billing system API
- QuickBooks for financial reconciliation
- Any payment processor with an API
The framework is always the same:
- External system fires webhook
- Azure or Halo runbook catches webhook
- Runbook orchestrates API calls to multiple systems
- Data flows back to HaloPSA
- Everything is tracked and logged
This is the kind of shit that Halo really excels at. The runbook system turns Halo into an automation platform that can integrate with basically anything that has an API or can send a webhook. You’re not limited to whatever pre-built integrations exist. No other PSA has such a powerful automation engine capable of so much.
The real-world benefits (because I’m not just doing this for fun)
Let me break down why this integration actually matters for my employer:
1. Eliminated Stripe fees entirely
Stripe was taking 2.9% + $0.30 per transaction. On a $1,000 invoice, that’s $29.30 gone. Alternative Payments’ allows me to pass that fee to the customer automatically. Over the course of a year, this adds up to real money.
2. Native HaloPSA tracking for everything
Every order, every invoice, every payment—all of it lives in HaloPSA natively. I don’t need to reconcile data between WooCommerce, Stripe, and Halo. The runbook handles all of that automatically. This saves hours of administrative bullshit every month.
3. Real-time payment processing
Customers get an immediate payment link after placing an order. No waiting for manual invoice generation. No email delays. Just instant “here’s how to pay” functionality. Customer experience is way better, and we get paid faster.
4. Proof that runbooks can handle complex workflows
This integration has multiple API calls, error handling, conditional logic, and webhook triggers. It’s way more complex than “run a script every hour to check something.” It proves that you can build legitimate business workflows entirely within the HaloPSA runbook ecosystem.
Final thoughts: Automation is about solving real problems
I didn’t build this integration because I was bored (okay, maybe a little bored). I built it because I had a real business need: reduce payment processing fees, eliminate manual reconciliation, and get everything tracked in HaloPSA automatically.
The fact that it also served as a great demo for a webinar was a bonus. But the core motivation was solving an actual problem that was costing me time and money.
That’s what automation should be about. Not automating for the sake of automation, but identifying genuine pain points and building solutions that eliminate those pain points permanently.
If you’re running any kind of e-commerce operation and using HaloPSA, this integration might be worth exploring. If you’re not doing e-commerce but you’re dealing with any external system that can fire webhooks, the pattern here is what matters. Webhook-triggered runbooks that orchestrate API calls across multiple systems—that’s the framework you can apply everywhere.
Catch the webinar (and a bonus podcast episode with me and Baxter) below.
Until next time, happy automating!
