CubeCart is deliberately kept slim, and third party plugins are how you add the things your particular store needs without carrying everything it does not. That is the right design. It does mean the quality of your store depends partly on the quality of the plugins you choose, and those vary more than people expect. These are the checks worth making before you install anything on a live store.
This is the most important question and it is the one least often asked.
CubeCart provides code hooks so that a plugin can add behaviour at defined points without altering CubeCart’s own files. A plugin built that way survives a CubeCart upgrade. A plugin that instead asks you to edit core files, or that quietly overwrites them during installation, does not: the next CubeCart update either reverts the change and breaks the plugin, or the plugin’s copy of an old file is left in place and breaks the store.
If installation instructions include the phrase “replace the following file”, stop and ask the author whether a hook-based version exists. Occasionally there is a genuine reason, but it should be an explicit decision on your part, recorded somewhere, because it becomes your problem at every future upgrade.
Look for a specific statement, not a vague one. “Works with CubeCart 6” is not a supported version range when CubeCart 6 has been through a great many releases with meaningful changes along the way. What you want to know is which release the plugin was last tested against, and how quickly the author has historically responded when a new CubeCart release changes something.
A plugin that has not been touched in three years is not necessarily broken, but it is a bet that nothing it depends on has changed.
Commercial plugins are usually licensed per store, and the licence is normally tied to the domain the store runs on. That is entirely reasonable, but it has practical consequences worth knowing before you buy rather than after:
Some commercial plugins ship encoded so the source cannot be read. There are legitimate commercial reasons for that and it is not a red flag on its own, but it does have consequences. Encoded files require a specific loader on the server, which ties the plugin to particular PHP versions, so an encoded plugin can end up being the reason you cannot move to a newer PHP. It also means that if the author disappears, nobody can fix it, including us.
For anything central to your store, that risk is worth pricing in. For a small convenience feature it matters much less.
Plugins that add data, such as extra product fields, customer information or order attributes, are storing that data somewhere. Find out where, and find out what happens if you uninstall. Some clean up after themselves and take your data with them. Some leave everything in place, which is untidy but recoverable, and is generally the safer behaviour.
This matters most for anything you would be upset to lose, and it is much easier to ask before installing than to discover afterwards.
A plugin that runs on every page load, adds its own stylesheets and scripts, or queries the database inside a product listing loop, will cost you speed on exactly the pages where speed converts to sales. Before and after is the only honest test. Time your category and product pages before you install, and again afterwards, and look at what has been added to the page source.
None of the above replaces testing. Take a copy of your store, install the plugin there, and put it through a real order: add to basket, apply any discount you use, check shipping and tax come out right, complete a payment in the gateway’s test mode, and look at the order in the admin area afterwards.
The failures that hurt are rarely a blank screen on installation. They are a plugin that quietly changes how tax is calculated, or how shipping is chosen, in a way nobody notices until a customer does.
We can provide a staging copy of your store for exactly this. If you would like one, or you want a second opinion on a plugin before you commit to it, open a ticket and ask.