Last updated: June 16, 2026

Payment bugs are rarely solved by staring at the final error message. The useful work is usually rebuilding the exact signed payload, field by field, until the application and the gateway are demonstrably signing the same thing.

The symptom

The Stainless & Aluminium checkout flow had a signature mismatch around Worldpay MD5/EMV handling. The visible checkout data looked reasonable, but the gateway rejected the request because the signature did not match the payload Worldpay expected.

That distinction matters. A user-facing checkout can look perfect while the server-side payment payload is subtly wrong. In this case, the debugging work focused on the exact values used in signing, not on the visual form alone.

The debugging path

I treated the signature as a reproducibility problem. First, isolate the fields used to create the MD5 input. Second, confirm ordering and formatting. Third, compare environment-specific values like installation IDs, currency, amount formatting, callback URLs, and shared-secret usage.

In a Next.js flow, I prefer to build this logic on the server. That keeps secrets out of the browser and makes it easier to add safe diagnostic logging for non-secret fields while the issue is being tracked.

The failure points worth checking

The most common mismatch sources are boring, which is exactly why they get missed: an amount sent as pounds instead of minor units, a field included in one environment but not another, a callback URL with a trailing slash difference, or a string encoded differently before hashing.

EMV-related fields add another layer because they can change the signed payload without changing the parts a product owner sees in the UI. The fix is not to guess; it is to print a safe comparison trace and reduce the signature to deterministic input.

The safer pattern for future checkout work

The checkout should have a single server-side function that builds the Worldpay payload, a second function that signs it, and tests or fixtures for known payload examples. That structure makes future gateway changes less fragile and makes payment failures easier to isolate.

If you are dealing with a similar integration issue, start with a focused API and checkout integration review rather than rewriting the whole checkout from scratch.