Because the messages were clear at some point on a machine he controlled.
This is what the article means by the payment processing being done on the client: Some client-side code (JavaScript? A mobile app?) would receive the message from the payment gateway, and send the success code to Dominos.
He may have used a debugger[1] to breakpoint the application where the application has a cleartext version of the traffic, however he might have also taken advantage of the fact that even if using HTTPS, if the programmer uses a certificate store the user has access to (which they usually do), they can install a custom root certificate and then use something like mitmproxy[1] or charles[2] to decode the traffic.
What's needed to make this secure is to have a token provided by the payment processing API that the server can verify but that the client cannot produce (or tamper with)[4].
This is what the article means by the payment processing being done on the client: Some client-side code (JavaScript? A mobile app?) would receive the message from the payment gateway, and send the success code to Dominos.
He may have used a debugger[1] to breakpoint the application where the application has a cleartext version of the traffic, however he might have also taken advantage of the fact that even if using HTTPS, if the programmer uses a certificate store the user has access to (which they usually do), they can install a custom root certificate and then use something like mitmproxy[1] or charles[2] to decode the traffic.
What's needed to make this secure is to have a token provided by the payment processing API that the server can verify but that the client cannot produce (or tamper with)[4].
[1]: https://securitycafe.ro/2015/01/28/intercepting-functions-fr...
[2]: https://mitmproxy.org/
[3]: https://www.charlesproxy.com/
[4]: https://en.wikipedia.org/wiki/Hash-based_message_authenticat...