You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that some people have custom orders numbers setup in WooCommerce, and PayPal returns an error about an invalid INVNUM value if it has non-ASCII characters.
[0] => Array
(
[L_ERRORCODE] => 10010
[L_SHORTMESSAGE] => Invalid Invoice
[L_LONGMESSAGE] => Non-ASCII invoice id is not supported
[L_SEVERITYCODE] => Error
)
An example of this was sent by a user in Europe. Their order numbers are coming out with the following value: n°110
The °, whatever that is, isn't acceptable by the API. One solution may be to simply remove all non-numeric values from the value that WooCommerce returns here.
That would return nothing but the 110 and PayPal would accept that, but I'm not sure how that would map back to the WooCommerce order for users where this comes up.
We could go ahead and do that, though, and that would also take care of the # that we're currently wiping out via str_replace().
The text was updated successfully, but these errors were encountered:
It seems that some people have custom orders numbers setup in WooCommerce, and PayPal returns an error about an invalid INVNUM value if it has non-ASCII characters.
[0] => Array
(
[L_ERRORCODE] => 10010
[L_SHORTMESSAGE] => Invalid Invoice
[L_LONGMESSAGE] => Non-ASCII invoice id is not supported
[L_SEVERITYCODE] => Error
)
An example of this was sent by a user in Europe. Their order numbers are coming out with the following value: n°110
The °, whatever that is, isn't acceptable by the API. One solution may be to simply remove all non-numeric values from the value that WooCommerce returns here.
$invoice = 'n°110';
$invoice = preg_replace("/[^0-9,.]/", "", $invoice);
echo $invoice;
That would return nothing but the 110 and PayPal would accept that, but I'm not sure how that would map back to the WooCommerce order for users where this comes up.
We could go ahead and do that, though, and that would also take care of the # that we're currently wiping out via str_replace().
The text was updated successfully, but these errors were encountered: