After completing a transaction with Paypal Website Payments Pro, the IPN callback is fired (uc_paypal_ipn()). The IPN code always uses the "website payments standard" server (uc_paypal_wps_server), even when wps is disabled.

This came up when running transactions in the sandbox; the IPN verification always failed, until I switched the "website payments standard" settings to match the "website payments pro" settings.

CommentFileSizeAuthor
#1 467456.paypal_sandbox.2.x.patch3.97 KBcha0s

Comments

cha0s’s picture

Assigned: Unassigned » cha0s
Status: Active » Needs review
StatusFileSize
new3.97 KB

I can see this being problematic in more than one way. For instance, imagine having a live order, then the admin switching to sandbox to test a txn, but the IPN for the first comes in, and fails, because it was live, but Ubercart is trying to auth. it as a sandbox txn.

In light of this, I propose a small change; PayPal leaves a little record of whether or not the txn was sandbox'd in the $order->data, and that's what's referred to when figuring out $host in the IPN code.

Patch follows, thoughts appreciated.

cha0s’s picture

Assigned: cha0s » Unassigned
YK85’s picture

Is this still an issue with Website Payments Pro?
I am looking to setup my site with Website Payments Pro and would appreciate any advice.
Thanks!

YK85’s picture

I was wondering if this is still an issue with Ubercart + Paypal payment?

tr’s picture

Version: 6.x-2.x-dev » 8.x-4.x-dev
Issue summary: View changes

This is the first time I've really looked into the PayPal module - it's just a mess. I will be trying to fix all these issues and rewrite the code as I port this to D8.

longwave’s picture

Status: Needs review » Fixed

At long last, the configuration of the three plugins is entirely separate in 8.x-4.x. This can't easily be backported to earlier versions without breaking backward compatibility.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.