woocommerce Case study
SnappPay UI Fixes
Four watch brands on the store are contractually excluded from SnappPay installments. The payment plugin's own behaviour was all or nothing. On top of that, the box clipped the tooltip explaining why installments were unavailable, so customers saw a dead button with no reason attached.
The business problem
Removing the SnappPay box entirely on excluded brands is the simple fix and the wrong one. The customer is then left with no idea whether installments exist at all, and support gets the question instead. Keeping the box meant the disabled state had to explain itself. That explanation rendered inside a container with overflow constraints, which cut it off on exactly the screen sizes where it mattered most.
What I delivered
- a2-snappay-blocked-product-override.php, which keeps the SnappPay box and the add-to-cart button visible on excluded brands while disabling only the calculator and credit controls.
- Suppression of the installment amount text on those products, so the page never shows a figure the customer cannot use.
- a2-snappay-blocked-tooltip-portal.php, which renders the explanatory tooltip outside the installment box entirely, escaping the container that was clipping it.
- Brand scoping by product category, evaluated on the product page only, so nothing in this logic runs on an archive or in the cart.
Technical approach
- The excluded brands are a single list shared by both modules, so the two can never disagree about which products are affected.
- Both modules check that the request is a single product view before doing anything, which keeps the cost off every other page type.
- I portal the tooltip rather than restyling it. Fighting a parent container's overflow with CSS overrides breaks the next time the payment plugin updates its markup.
- I do not touch the SnappPay plugin itself. Everything happens in MU plugins around it, so a vendor update cannot silently revert the behaviour.
Result and evidence
Customers on excluded brands now see that installments exist, see that they are unavailable for this product, and see why, without opening a support conversation. The disabled state is explained at the point of confusion.
Commercial value
Unexplained payment friction becomes a support ticket or an abandoned cart. Explaining a restriction costs almost nothing, and usually less than the conversation it prevents.
Readable implementation brief
implementation_brief {
project: "SnappPay UI Fixes"
files: "a2-snappay-blocked-product-override.php (279 lines)
a2-snappay-blocked-tooltip-portal.php (175 lines)"
scope: "four excluded watch brands, product pages only"
keeps: "SnappPay box and add-to-cart visible"
disables: "calculator and credit buttons, installment figure"
tooltip: "rendered outside the box to escape overflow clipping"
boundary: "vendor plugin untouched; behaviour lives in MU"
}What this project shows
Hiding a control you cannot support is the wrong instinct, and worth resisting. A visible disabled state with a reason nearly always serves the customer better than an element that simply is not there.
Portalling the tooltip instead of overriding overflow is the maintainable choice. I would rather move an element than win a specificity argument with a plugin that will be updated next month.