It's pretty clear that whoever designed this API didn't even take an passing glance at the security or reliability implications. There are 2 ways (from the linked slides) for a merchant to report cashback activity to MS:
1) Tracking pixel: this gives instant update to the user, but is completely insecure and also fairly unreliable (image fails to load, cross site https issues, random network hickup, etc).
2) FTP upload of a plain text list: yes really, plain old FTP. This is at least reliable but is only authenticated by a plain-text user/pass. The list does not have any signature for authentication.
I'm not a web guy at all (I'm an ASIC hardware guy) and off the top of my head I can think of 2 real solutions:
The right way: SOAP. Gives instant update to the user, should be trivial in any backend web language, is reliable, is trivial to encrypt (https), is trivial to authenticate (a simple shared secret would be enough).
A reasonable way: both of the existing ones. The tracking pixel is used to provide instant user update in 99% of the cases, but the transaction is marked pending. At the end of the day the text list is uploaded to the FTP. Compare the 2 lists, approving all that match and flagging for review any that don't (extra, missing, or different). As an added bonus a cryptographic signature should be added to the list.
The problem with simply adding a MAC to the existing tracking pixel is that it doesn't fix the reliability issue. Also the advantage of the current tracking pixel is that it's stupidly easy to implement. If you're going to load in some libraries to do the MAC calculation on the server, you might as well load in a SOAP library and do the transaction properly.
It really boggles the mind that a bogus transaction could actually be paid out. That indicates there is absolutely no auditing or rationalization between what the e-tailer thinks should be paid out and what MS thinks should be paid out. Even something as stupid as end-of-month totals should flag that there are bogus transactions.