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, and the tooltip explaining why a customer could not use installments was being clipped by the box it lived inside, so customers saw a dead button with no reason attached.

Back to projects All case studies MU plugin showcase

The business problem

Removing the SnappPay box entirely on excluded brands is the simple fix and the wrong one: the customer then has no idea whether installments exist at all, and support gets the question instead. Keeping the box meant the disabled state had to explain itself, and the explanation was rendering inside a container with overflow constraints that 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 no figure is displayed that the customer cannot actually 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.
The tooltip is portalled rather than restyled. Fighting a parent container's overflow with CSS overrides is a fix that breaks the next time the payment plugin updates its markup.
The SnappPay plugin itself is not modified. Everything is done from 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

Payment friction that is unexplained becomes a support ticket or an abandoned cart. Explaining a restriction costs almost nothing and is usually cheaper than the conversation it prevents.

implementation-brief.readme

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

The instinct to hide a control you cannot support is worth resisting. A visible disabled state with a reason is nearly always better for the customer 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.