PayPal RESTful API Payment Module

That's not helpful, I'm looking for a "pattern" for the failure so I need specifics.

My best guess is that, for the sites that are auto-disabling after successfully retrieving the PayPal OAuth token, the required changes to the order_totals.php class were not applied: https://github.com/lat9/paypalr/wiki/Required-changes-to-%60-includes-classes-order_total.php%60

I just installed Paypal Restful 1.01 on our test server and came up against an issue with card processing.

2024-03-09 14:04:23: (checkout_process) ==> Start createOrder
TokenCache::get, using saved access-token; expires in 32362 seconds.
The curlPost (v2/checkout/orders) request was unsuccessful.
{
    "errNum": 400,
    "errMsg": "",
    "curlErrno": 0,
    "name": "INVALID_REQUEST",
    "message": "Request is not well-formed, syntactically incorrect, or violates schema.",
    "details": [
        {
            "field": "\/purchase_units\/@reference_id=='default'\/supplementary_data\/card\/level3\/ships_from_postal_code",
            "value": "TQ12 5TZ",
            "location": "body",
            "issue": "must match \"^[a-zA-Z0-9_'.-]*$\""
        }
    ],
    "debug_id": "8a641239069c5"
}

...

2024-03-09 14:04:23: (checkout_process) ==> End createOrderAn error occurred when we tried to process your credit card. Please try again, select an alternate payment method or contact us for assistance.

A correctly-formatted UK postcode has a space in it, as above. Paypal appears to have rejected it because it isn't expecting a space. This is not necessarily the fault of the Zen Cart payment module but I managed to get around it by editing includes/modules/payment/paypal/PayPalRestful/Zc2Pp/CreatePayPalOrderRequest.php, changing:

        if (SHIPPING_ORIGIN_ZIP !== '') {
            $level_3['ships_from_postal_code'] = SHIPPING_ORIGIN_ZIP;
        }

to:

        if (SHIPPING_ORIGIN_ZIP !== '') {
            $level_3['ships_from_postal_code'] = str_replace(' ', '', SHIPPING_ORIGIN_ZIP);
        }

at line 466 to remove the space.

After that, the card payment went through fine. It might be worth looking into this further as the workaround might not be the right way to fix it.

I couldn't find anything in the Paypal API docs that specifies the format of the ships_from_postal_code field. Only that it shoudl be 1-60 characters long.

BillJ:

I just installed Paypal Restful 1.01 on our test server and came up against an issue with card processing.

2024-03-09 14:04:23: (checkout_process) ==> Start createOrder
TokenCache::get, using saved access-token; expires in 32362 seconds.
The curlPost (v2/checkout/orders) request was unsuccessful.
{
"errNum": 400,
"errMsg": "",
"curlErrno": 0,
"name": "INVALID_REQUEST",
"message": "Request is not well-formed, syntactically incorrect, or violates schema.",
"details": [
{
"field": "/purchase_units/@reference_id=='default'/supplementary_data/card/level3/ships_from_postal_code",
"value": "TQ12 5TZ",
"location": "body",
"issue": "must match "^[a-zA-Z0-9_'.-]*$""
}
],
"debug_id": "8a641239069c5"
}

...

2024-03-09 14:04:23: (checkout_process) ==> End createOrderAn error occurred when we tried to process your credit card. Please try again, select an alternate payment method or contact us for assistance.

> 
> A correctly-formatted UK postcode has a space in it, as above. Paypal appears to have rejected it because it isn't expecting a space. This is not necessarily the fault of the Zen Cart payment module but I managed to get around it by editing *includes/modules/payment/paypal/PayPalRestful/Zc2Pp/CreatePayPalOrderRequest.php*, changing:
> 
> ```
        if (SHIPPING_ORIGIN_ZIP !== '') {
            $level_3['ships_from_postal_code'] = SHIPPING_ORIGIN_ZIP;
        }

to:

    if (SHIPPING_ORIGIN_ZIP !== '') {
        $level_3['ships_from_postal_code'] = str_replace(' ', '', SHIPPING_ORIGIN_ZIP);
    }

> 
> at line 466 to remove the space.
> 
> After that, the card payment went through fine. It might be worth looking into this further as the workaround might not be the right way to fix it.

> **BillJ:**
>
> I couldn't find anything in the Paypal API docs that specifies the format of the *ships_from_postal_code* field. Only that it shoudl be 1-60 characters long.
Thanks for sussing that out; I've opened a GitHub issue to track the change (<https://github.com/lat9/paypalr/issues/14>) and use your suggested correction.

lat9:

Thanks for sussing that out; I've opened a GitHub issue to track the change (https://github.com/lat9/paypalr/issues/14) and use your suggested correction.
Thanks. Other than that it looks great and I'm going to install it on our production server. Since it replaces Paypal Express, are there any plans to implement the Paypal Express Checkout button?

BillJ:

Thanks. Other than that it looks great and I'm going to install it on our production server. Since it replaces Paypal Express, are there any plans to implement the Paypal Express Checkout button?
I've got no plans for a PayPal Express Checkout button at this time; the best I can offer is that the payment module works with the guest-checkout feature of One-Page Checkout.

lat9:

I've got no plans for a PayPal Express Checkout button at this time; the best I can offer is that the payment module works with the guest-checkout feature of One-Page Checkout.
That's a fair trade. I always thought the Express Checkout button added a lot of complexity to the checkout code.

:thumbsup:

Will this be part of the ZC 2.0 release?

Webskipper:

Will this be part of the ZC 2.0 release?
Nope, it needs to "get its feet wet" before committing to core.

ZC 1.5.8a
PHP 8.1.27
PayPal Checkout (RESTful) 1.0.1
OPC 2.4.6
Square WebPay 1.2.0

I get this warning when voiding a transaction

[20-Mar-2024 14:29:00 Europe/London] Request URI: /MY_ADMIN/index.php?cmd=orders&page=1&oID=1391&action=doVoid, IP address: xx.xx.xx.xx, Language id 1
#0 /home/MY_DOMAIN/public_html/includes/modules/payment/paypal/PayPalRestful/Admin/DoVoid.php(92): zen_debug_error_handler()
#1 /home/MY_DOMAIN/public_html/includes/modules/payment/paypalr.php(1912): PayPalRestful\Admin\DoVoid->__construct()
#2 /home/MY_DOMAIN/public_html/MY_ADMIN/orders.php(405): paypalr->_doVoid()
#3 /home/MY_DOMAIN/public_html/MY_ADMIN/index.php(11): require('...')
--> PHP Warning: Undefined variable $last_auth_txn in /home/MY_DOMAIN/public_html/includes/modules/payment/paypal/PayPalRestful/Admin/DoVoid.php on line 92.

[20-Mar-2024 14:29:00 Europe/London] Request URI: /MY_ADMIN/index.php?cmd=orders&page=1&oID=1391&action=doVoid, IP address: xx.xx.xx.xx, Language id 1
#0 /home/MY_DOMAIN/public_html/includes/modules/payment/paypal/PayPalRestful/Admin/DoVoid.php(92): zen_debug_error_handler()
#1 /home/MY_DOMAIN/public_html/includes/modules/payment/paypalr.php(1912): PayPalRestful\Admin\DoVoid->__construct()
#2 /home/MY_DOMAIN/public_html/MY_ADMIN/orders.php(405): paypalr->_doVoid()
#3 /home/MY_DOMAIN/public_html/MY_ADMIN/index.php(11): require('...')
--> PHP Warning: Trying to access array offset on value of type null in /home/MY_DOMAIN/public_html/includes/modules/payment/paypal/PayPalRestful/Admin/DoVoid.php on line 92.

and because of this (I assume) the Trans ID is blank in the admin orders 'voided' comments block

VOIDED. Trans ID: [blank]
Transaction voided.

GitHub issue created to track the correction: https://github.com/lat9/paypalr/issues/15

lat9:

GitHub issue created to track the correction: https://github.com/lat9/paypalr/issues/15
... and correction provided in this GitHub commit: https://github.com/lat9/paypalr/commit/1e9f3a906cbe9a6452675f4eb7172c2de30bafad

I noticed some behaviour yesterday that I didn't expect (and some that I did, for contrast).

Firstly, what I did expect:
A customer tried to place an order and Paypal didn't trust the card. I received an e-mail:
"ALERT: PayPal Checkout Error (Lost/Stolen/Fraudulent Card)" containing some of the card details. No order was created and the customer tried and failed a couple more times before trying a different card and paying successfully. This time the order was created.

Then what I didn't expect:
A different customer tried to place an order and their card was declined for some unspecified reason. I received an e-mail:
"ALERT: PayPal Checkout Error (Order Requires Attention)", "The status for order #23510 was forced to "Pending" due to a PayPal response status of 'DECLINED'"
The order was created and the status set to "Pending" as per the e-mail notification.

When I spoke to the customer to ask for payment via another card (they are a regular business-to-business customer) they weren't aware the payment had failed. However, I cannot say whether that is because they were not notified or just because they didn't notice and that isn't really the issue.
We are not used to seeing an order being created after a failed payment and we have always been able to assume that an order from the web-site is paid for and ready to be shipped, without any further examination of its status. Is this expected behaviour? I suppose it must be since there was a specific e-mail notification for that event.

I forgot to say I'm using ZC 1.58a, OPC 2.4.6 and PP Restful 1.0.1

BillJ:

I noticed some behaviour yesterday that I didn't expect (and some that I did, for contrast).

Firstly, what I did expect:
A customer tried to place an order and Paypal didn't trust the card. I received an e-mail:
"ALERT: PayPal Checkout Error (Lost/Stolen/Fraudulent Card)" containing some of the card details. No order was created and the customer tried and failed a couple more times before trying a different card and paying successfully. This time the order was created.

Then what I didn't expect:
A different customer tried to place an order and their card was declined for some unspecified reason. I received an e-mail:
"ALERT: PayPal Checkout Error (Order Requires Attention)", "The status for order #23510 was forced to "Pending" due to a PayPal response status of 'DECLINED'"
The order was created and the status set to "Pending" as per the e-mail notification.

When I spoke to the customer to ask for payment via another card (they are a regular business-to-business customer) they weren't aware the payment had failed. However, I cannot say whether that is because they were not notified or just because they didn't notice and that isn't really the issue.
We are not used to seeing an order being created after a failed payment and we have always been able to assume that an order from the web-site is paid for and ready to be shipped, without any further examination of its status. Is this expected behaviour? I suppose it must be since there was a specific e-mail notification for that event.
Are you running paypalr in Auth-Only or Final-Payment mode? Do you know if there was an SCA path taken when the payment was processed?

I'll note that what you describe as unexpected ***is ***unexpected!

Thank you.

lat9:

Are you running paypalr in Auth-Only or Final-Payment mode?
I have Payment Action set to "Final Sale" in the paypalr configuration, if that's the setting you mean.

lat9:

Do you know if there was an SCA path taken when the payment was processed?
I don't know, sorry. Would it be logged somewhere by paypalr? I have debugging switched on. There was a Paypal transaction number stored in Zen Cart but it was not recognised when I searched for it in our Paypal account.
The card the customer used was not their usual card that we keep on file for telephone orders and they don't often order online anyway so it might have triggered SCA. However that is just speculation.

BillJ:

Thank you.

I have Payment Action set to "Final Sale" in the paypalr configuration, if that's the setting you mean.

I don't know, sorry. Would it be logged somewhere by paypalr? I have debugging switched on. There was a Paypal transaction number stored in Zen Cart but it was not recognised when I searched for it in our Paypal account.
The card the customer used was not their usual card that we keep on file for telephone orders and they don't often order online anyway so it might have triggered SCA. However that is just speculation.
If debugging was switched on when the errant transaction was run, there will be a paypalr-c-{cid}-ffflll-yyyymmdd.log present. {cid} is the customer's ID and {ffflll} is the first 3 characters of the customer's first/last name. If you find such a log, send me a PM and I'll send back my direct email address.

lat9:

If debugging was switched on when the errant transaction was run, there will be a paypalr-c-{cid}-ffflll-yyyymmdd.log present. {cid} is the customer's ID and {ffflll} is the first 3 characters of the customer's first/last name. If you find such a log, send me a PM and I'll send back my direct email address.
Thank you. Log on its way.
I can see from the log that the card failed the CVV check. The customer probably mis-typed it. Despite having an account, they had checked out as a guest using OPC.