Re:Solution (Score 1)

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).

Exactly. And I wonder if they've done that already, and simply not updated their integration docs. There's no way to pass a transaction date with the pixel, so Bountii must've first played with this back in January. It would've been nice to know how long the Jan 24 forgeries took to clear. The fact that the Oct 24th purchase hadn't become Available by Nov 4th suggests that Bing might now require batch confirmation for all transactions. Or perhaps the merchant used the Merchant Center interface to flag the transaction -- I know in the ecommerce systems I've been involved with, staff review the transaction log for anything unusual.

There is still that Denial of Service problem -- a user claiming all "future" order IDs and preventing legitimate customers from getting their credits. I thought Bing might've simply prevented any given customer from submitting two claims with the same merchant ID & order ID (classic "transaction token"/page reload stuff), but the screenshots of the Merchant Center suggest that Bing isn't dong that (yet).

My favorite part is that on page 20 of the Bing Cashback integration guide they say that the pixel hack is "recommended" for reporting purchases. Recommended!

Second favorite: that Samir at Bountii posted this on his blog without contacting Bing first. He should've followed something like the RFPolicy protocol (http://www.wiretrip.net/rfp/policy.html).