Siriusware
E-commerce
Taxes
A Problem with Taxes
Introduction
If I may be frank, this is an older ticket, so I am a bit fuzzy on the details (I need to keep better notes on more notable tickets). What I can say is that Verndale had overhauled the entire e-commerce site for this particular client before it was passed on to our team. Naturally, there were a few bugs after the production release, and we were on the hook for them. In hindsight, the client was a little annoyed with how many bugs there were, but in our defense, their products are seasonal, which meant that each quarter they would release completely new products that were mostly unrelated to the previous quarter. To top things off, they did NOT fully test their products in the QA environment before the start of the season and just released them to production. So from that perspective, there is a case to be made that it was actually surprising how few bugs there were.
Siriusware
Siriusware is the ticketing point of sale software that runs the whole show. All the products on our site come from querying Siriusware APIs. This includes, prices, availability dates, quantities, products, what variants are available, the ability to pay with payment plans, and of course taxes. What is quite strange is that Siriusware trusts the API caller implicitly without question or validation. Although all the pricing information, tax information, and ticket quantities are all determined by Siriusware, when creating an order, the API caller must send all these values AND Sirius will accept them no matter what. NO MATTER WHAT. The repercussions of this behaviour can be seen here.
The Actual Problem
One morning, we receive a ticket from our client stating that pricing is incorrect when using the newly released payment plan feature. But of course it is not on all products, it is only on particular products. This particular product is the family passes. On our end, the "product" with the problem was the VariantItem Item. Yes, that was not a typo, in the db, it is literally called the VariantItem Item. Anyways, the point is that the price is wrong and at this point I do not even know what the payment plan feature even is, so you can forget me even trying to recreate the issue. After playing around with the numbers I see that the discrepency between what is being charged and what the actual total is the tax. What is strange is that we send the tax amount to Sirius in the payload and it is correct for everything except for Variant Item Items when using the payment plan (aka separating the payments over multiple charges). After reading and rereading the documentation and testing what feels like hundreds of payload values to Sirius, it turns out that we need to explicitly state the the taxes for each line item and not just the total.
In Montreal, there are two chargeable sales taxes:
5% GST + 9.975% QST for a total of 14.975%
Some Sirius people might call them TaxA and TaxB (i.e., the people who made Siriusware do). For some reason, we need to send TaxA and TaxB as separate values in the payload, but only for payment plans. So now I have to refactor the tax-calculating logic in the cart/checkout flow to split everything, just in case the user wants to select a payment plan at the end of the checkout, even though Siriusware has all the tax information in their own system.
We are already sending the total tax that needs to be charged, but now we have to split it up line by line. This tax price and information, however, is data that comes from Sirius in the first place. So at the time of the order, we are sending Siriusware the product we are ordering, the total tax to be paid, TaxA, TaxB, and the price of the product, even though all that information is stored in Sirius. To top things off, this is not mentioned anywhere in the documentation as being necessary (probably because it is a bug).
Anyways, it actually took another ticket/edge case for me to completely figure out and fix this issue, but at the end of the day, it was finally fixed.
Lessons Learned
Have a better QA environment if you want to catch bugs sooner
Don't use Siriusware
Apr 24, 2026