5113ced7e3
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. |
||
---|---|---|
.. | ||
Business/PayPal |