Debugging a Worldpay MD5/EMV signature mismatch

Payment bugs are rarely solved by staring at the final error message. What works is rebuilding the exact signed payload, field by field, until you can show that the application and the gateway are 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.

A checkout can look perfect to the customer while the payload built on the server is slightly wrong. So the debugging here was about the exact values that went into the signature, and the form on screen was only a starting point.

The debugging path

I treated the signature as something to reproduce. I isolated the fields that make up the MD5 input, then confirmed their order and formatting, then compared the values that differ between environments: installation IDs, currency, amount formatting, callback URLs, and how the shared secret is used.

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 usual causes of a mismatch are dull ones, and they get missed for that reason: an amount sent in pounds instead of minor units, a field included in one environment and not another, a callback URL that differs by a trailing slash, or a string encoded differently before hashing.

EMV fields add another layer, because they can change the signed payload without changing anything a product owner sees on screen. Guessing does not help here. Print a comparison trace with the secret left out, and reduce the signature to input that comes out the same every time.

A safer structure for checkout code

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 problem, start with an API and checkout integration review rather than rewriting the whole checkout from scratch.