CubeCart 6.8.2 and 6.8.3: When the Invoice Disagrees

CubeCart has had three maintenance releases in eleven days: 6.8.1 on 21 September, 6.8.2 on 1 October and 6.8.3 on 2 October. None of them contains a security fix and none changes the database, so there is no rush in the way there is with a security release. Two of them, though, fix the same kind of fault, and it is the kind worth acting on because it leaves a mess behind that upgrading does not clear up.

We covered 6.8.1 separately in the fix tax-inclusive stores need. This piece covers 6.8.2 and 6.8.3, and starts with the one that most stores should look at.

When the invoice disagrees with what the customer paid

6.8.3 fixes a single thing, and it affects any store using quantity pricing or group pricing, which is most trade and wholesale shops.

If a customer changed the quantity part way through checkout and that change crossed a price break, the order line kept the old unit price. The customer was charged correctly. The invoice and the order confirmation email were not: the line total disagreed with the subtotal printed beneath it.

That is a bad fault to have quietly, because the person most likely to notice is the customer, and what they are looking at is a document with arithmetic that does not add up. In a trade context it invites a query about every invoice you have ever sent them.

Upgrading does not repair orders that were already placed. Those have to be corrected by hand.

Which orders to look at

The exposure is narrow and you can bound it:

1. Only stores with quantity or group pricing configured. If every product has one price for everybody, there is nothing here for you.
2. Only orders where the quantity was changed during checkout. A basket filled once and paid for straight away was priced correctly.
3. Only orders placed since you installed 6.8.0 or later.

On a typical store that is a short list. Open each one and check that the line total is the unit price multiplied by the quantity, and that it agrees with the subtotal. The figure that was always right is the amount taken by the payment gateway, so that is your reference. The order history and CubeCart’s audit log will tell you which orders were edited if you are not sure.

This is the second release in a fortnight to fix a mismatch of this sort. 6.8.1 dealt with a related one, where discounted lines on a tax-inclusive store displayed at full list price and, worse, saving such an order in the admin panel wrote the wrong figure into the stored price. If you did not read that one, it is worth two minutes, because the checking job is the same and the two faults can both be present on the same store.

What else 6.8.2 fixed

Eight fixes, and these are the ones that affect how the store behaves rather than how it looks:

• An abandoned cart reminder could be sent to a customer who had already paid. It happened in gateway flows where the request taking the payment carries on running after the receipt has cleared the basket. Embarrassing rather than harmful, but it is the sort of email that makes a shop look careless.
• Registering with an email address already on file could create a second account. The duplicate check was able to read a cached query result and miss an account created moments earlier. It now bypasses the cache.
• A third-party discount extension could blank the whole storefront. If it saved a coupon record without an expected key, the result was a fatal error on PHP 8 that affected every page for that visitor and wrote nothing to the error log, which is exactly what a hosting problem looks like. Very few stores will have hit it, but it is worth knowing the shape of it: when a site goes blank with an empty error log, an extension is a more likely culprit than the server.

The remaining five are all in the Atrium skin introduced in 6.8.0, so they only matter if you have moved to it:

• Price Each and Price in the basket are shown the right way round.
• A new setting chooses whether catalogue thumbnails are cropped square or shown whole.
• A new setting controls the size of the header logo.
• Long category flyout menus stay on screen and scroll, instead of running off the bottom of the page.
• A deep link to a product tab, such as the one offered by “Quantity discounts available”, now opens that tab.

If you have copied Atrium to make your own skin, the two new settings will not appear. They live in the skin’s config.xml, and a copy made before 6.8.2 does not have them. They have to be added to your copy by hand.

How urgently to take these

There are no security fixes in any of the three releases, which is a useful thing to be able to say plainly. Compare that with the 6.7.x security releases, where waiting genuinely did carry a risk.

So the sensible reading is this. If your store uses quantity or group pricing, or works in tax-inclusive prices, take 6.8.3 soon and do the order check, because every day without it is another day in which a document can go out disagreeing with itself. If neither applies, and you have not moved to Atrium, 6.8.3 can wait for your next maintenance window along with everything else.

Either way, since all three releases skip the database, this is a file update with the usual precautions: a backup you have actually tested, a trial run on a copy if the store is busy, and a full pass through the checkout afterwards.

If we host your store

Fully managed stores are kept current, so there is nothing for you to do. If you manage your own updates and would like us to take this one on, open a ticket and we will do it. If you think an order may have been written with the wrong line price, send us the order numbers and we will compare what is stored against what the gateway actually took.