The Options fields found in
/PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have
never been extracted in the proper way. In fact, I'd be surprised if
anyone found the previous method of extraction useful at all.
I discovered this bug when I needed to lookup the Options selected
during payment, and found they weren't returned by the API.
Specifically, the value inside the SOAP tags, which is what the API
previously returned, are simply not useful: they are typically empty.
The interesting data is stored in the attributes of 'name' and 'value'.
Note, BTW, that each PaymentItem can have its own set of Options. This
code added herein properly extracts the Options data for each
PaymentItem, and places it both in the Options field for that
PaymentItem, and in the array in the PII_Options "convenience" field.
As can be seen in the accompanying changes to t/OptionsFields.t, the
return values of the Options data is now a hash rather than a list. I
believe this API-user-visible change is appropriate since a hash is
ultimately the natural representation of this data, and since having the
Options as an array of empty strings wasn't useful, anyway.
Nevertheless, if existing user code of this API relies on Options being
an array of empty strings (which I suppose could have been usefully used
in scalar context to get the count of options in the record), this
change theoretically creates a user-visible change in the API. I can't
imagine anyone found the previous return value useful in the past
anyway, so I'd be surprised if anyone relies on this mis-feature. If
they did, they can simply change their code to:
scalar keys ...{Options}
instead of:
scalar @...{Options}
However, since this is technically an API change, I've updated the
Changes file and the module documentation to mention it.
I'm using Emacs to edit this file and wanted to be sure that I matched
the existing coding style in use in this file. I believe these settings
properly match the coding style for this file.
