that's exactly what I was getting too,
and was getting 'not eligible' for seller protection
even though the store was (still is) set to only allow checking out with identical billing/delivery address.
i think i figured it out, or perhaps it was just coincidence,
i remember comparing a fresh virgin set of DB’s,
from 1.3.6 / 1.3.9h / 1.5.0
i noticed that the 1.3.9 to 1.5.0 upgrade changed some tables (adding some extra fields, changed some to NULL or empty),
my upgrade did not amend the old stuff, just left them without,
so i manually rebuilt my 1.3.9 DB to 1.5.0 specs (cutting and pasting using two windows of notepad++) and imported it to a fresh install of 1.5.0 ... after dropping all the virgin 1.5.0 tables first.
at bit time consuming...
but after that and,
including a subsequent ‘upgrade’ (the easy way) to 1.5.1
the problem disappeared... i now receive a detailed order, whether it’s one item or many, including the attributes selected if any.
perhaps use winmerge (or similar) to compare the tables of an old backup (store populated one) to your current 1.5.x backup (store populated one),
change some ‘’ to NULL (or visa versa i cannot remember which) you’ll see in the 1.5.x table structure what it’s supposed to be ,
and
add the missing NULL or ‘’ to the table (or two, again i cannot remember which table or tables) that are missing the field, again it’ll be specified in the 1.5.x table structure(s).
NB: i left the 1.5.0 store configuration tables alone, i.e. i did not add that stuff from the 1.3.9 DB,
but transferred/incorporated the rest;
zones, addresses, emails, categories and attributes, products, counters (and many more) etc ~ i wanted to keep that data
and regarding previously installed mods, i added the mod tables that i still wanted to use. (not forgetting to FTP the mod files too!)
as i said a bit of a hack but you should get the results
sorry i cannot be more specific, but it was the route to solving the problem, i’m sure
