@simon,
I may have found it.
In the PayPal Pro module I'd written this comment:
Code:
// if State is not supplied, repeat the city so that it's not blank, otherwise PayPal croaks
if ((!isset($optionsShip['SHIPTOSTATE']) || trim($optionsShip['SHIPTOSTATE']) == '') && isset($optionsShip['SHIPTOCITY'])) $optionsShip['SHIPTOSTATE'] = $optionsShip['SHIPTOCITY'];
... presumably because PayPal was rejecting orders that had no State filled in.
In the Express Checkout module the same logic is also present:
Code:
// if State is not supplied, repeat the city so that it's not blank, otherwise PayPal croaks
if ((!isset($options['PAYMENTREQUEST_0_SHIPTOSTATE']) || trim($options['PAYMENTREQUEST_0_SHIPTOSTATE']) == '') && !empty($options['PAYMENTREQUEST_0_SHIPTOCITY'])) {
$options['PAYMENTREQUEST_0_SHIPTOSTATE'] = $options['PAYMENTREQUEST_0_SHIPTOCITY'];
}
... and later ...
'ship_state' => (isset($response['PAYMENTREQUEST_0_SHIPTOSTATE']) && $response['PAYMENTREQUEST_0_SHIPTOSTATE'] !='' ? urldecode($response['PAYMENTREQUEST_0_SHIPTOSTATE']) : urldecode($response['PAYMENTREQUEST_0_SHIPTOCITY'])),
When receiving the order back from PayPal and creating address-book entries for it, there's no checking to see whether the city and state are identical strings in order to revert the duplication.
Granted, it's not always true that an exact duplication is "wrong". Consider the city of "New York" in the state of "New York".
I suppose in the NY case though there's likely already a Zone for it, so maybe we could only blank-out the State if it matches the City and there's no Zone found for it? ZC only uses the State name if there's no zone match, so that'd probably be a safe cleanup.
I suppose the simple way to test whether the problem is still relevant is to change the logic to use an empty string instead of doing the city substitution, and see if the same order gives you any errors.
Bookmarks