Paypal Express - Error 10485 Payment has not been authorized by user

[John Sieber]

Hi all,

We are running into an issue with a small percentage of orders that are using PayPal Express for payment. When we attempt to capture the funds when fulfilling the order, we are unable to as we get the following error:

10485 - Payment has not been authorized by the user

I'm not able to replicate this issue and don't understand how the order can be placed without receiving an ack value of success and a token.

Is anyone else seeing transactions that allowed the order to be completed but are unable to be captured due to the error 10485 - Payment has not been authorized by the user?

Hoping someone else has run into this issue and has an explanation or a bug fix for the integration that will prevent these orders from going through.

-John

[John Sieber]

After getting a chance to dig into this deeper it appears that the current PayPal Express Integration is not designed to do separate authorization and captures. According to the documentation, the current integration saves a token returned from Paypal and uses that to capture the funds. This Express token is only valid for 3 hours and can be extended to 72 hours by PayPal Customer Service. To properly authorize payments for later captures the following sent to PayPal should have a value of "Authorization" not "Sale":

PAYMENTREQUEST_0_PAYMENTACTION

This will return an authorizationID in place of a token and the authorizationID should be valid for up to 29 days and guaranteed for 3. 

[John Sieber]

Curious if others on the list are using PayPal Express and run into issues with capturing payments after the token expires. I see I can do a separate authorization, but I need to store the authorization Id to complete the capture that is returned by the doExpressCheckoutPayment method. Looking at the integration, this is called when trying to capture the payment in the Slatwall admin, but it would seem that this should happen when the order is placed on the front end. 

The other option would be to capture payments when the order is placed. Is anyone doing that successfully. We end up not being able to capture payments for orders that are placed over a long weekend and would like to resolve the issue.

[Chris Kent]

Hi John,

Thank you for looking into this in such detail. 

I do have a number of clients that are using/have used PayPal Express integration. I have not noticed this issue, I have checked and all clients currently using PayPal Express are set to "receive" payment so therefore should not encounter the deferred payment capture. 

Or, is the problem you are encountering

• not an authorise & charge at delivery time delay 
• but a delay from the initial PayPal Express token generation to the place order and take payment
  

If it is the second scenario, then is the customer sitting on the final place order stage of checkout for over the 3 hours or coming back to the place order stage of checkout.

Also, if it is the second scenario, then an alternative solution could be to automatically time-out the any old order payment if it is 3 hours and force a new order payment, this would then request a new token from PayPal.

I am happy to help talk this through and test solutions on a test site to help you. Just let me know.

Chris.

[John Sieber]

Hi Chris,

Thanks for your reply! Setting the payment method to "receive" payment is the key issue. I tested this today and yes, it works correctly when we immediately capture the payment upon completion of the purchase. This is great news for us and will allow us to work around the issue we are having with not being able to capture all of the payments. Thanks for pointing out that you have all of your sites set to "receive" and that is working well for you.

We had ours set to "none" and then it followed the same fulfillment process that our orders using authorize.net use where we fulfill and capture payment at the time of shipping the order. The majority of PayPal orders worked correctly using this process but we would run into a small percentage of orders that we would be unable to capture. The majority of these would happen to orders placed on a Friday night that we would not capture until Monday morning when they were fulfilled. We would have more over a three day weekend.

When the setting is set to "none" it does use the token when capturing the funds in the backend of Slatwall. The token can be extended to last for 72 hours but that is the limit. The NPV API does allow for one to authorize the payment and then capture it within 29 days when the order is fulfilled but it appears that the integration flow would need to change as you are returned the authorization id that is needed when performing the "doExpressCheckoutPayment" option and currently this step happens it seems only when capturing the payment in the Slatwall Admin when the integration is set to "none" instead of "receive".

I think if people want to authorize and then capture once a product is delivered, the integration would need to be changed to use the authorization id instead of the original token. For now, we are happy to capture the payment right away using the "receive" option. Thanks for pointing that out!

-John

[Chris Kent]

Hi John,

Good to hear that it is now working for you. 

I have always set PayPal to "receive" as it seemed to be the right (only) setting.

But, interesting to know that if it was left blank then PayPal Express works as a authorise and capture type of payment method, as long as this is within the 3 hour default window. Will have to review this for future reference.

72 hours might just work with a fast turnaround of order payment to fulfilment, but as you have found, weekends, holidays and any delay in fulfilment may cause issues.

Chris.