Since few days the adaptive payments (both preapprovals and chained) seems to be broken. When we send the user to paypal to complete the order (chained) or to authorize the preapproval (preapprovals), they get a generic "invalid transaction" error. Tested the flow, we get the same error and looking to the console we can see this error on the checkout.js file in the paypal object directory:
Uncaught TypeError: PAYPAL.AP.Subflow is not a constructor
at checkout.js:11
(anonymous) @ checkout.js:11
Seems something has broken on paypal side. Anyone with the same issue? Workarounds?
Cheers, Fil
We've finally figured out what was wrong.
Trying the complete debugging of the call to the svcs endpoint we've discovered that since few days (first time from 2013), we started getting an odd response from the paypal server to our SOAP request as:
{"faultstring":"Unknown Content-Encoding","faultcode":"HTTP"}
We've then thought to some issue in the "transportation" of the call to paypal servers and we've tryed to add something in the headers.
First, we discovered that in our http header request some line that we've never used before was missing, for example:
"X-PAYPAL-DEVICE-IPADDRESS: " . $_SERVER['REMOTE_ADDR'] . "\r\n" ;
But this didn't solve the issue. Then we've added a new line in the soap client array:
'compression' => SOAP_COMPRESSION_ACCEPT,
Adding this solved the issue but no one ever adviced us about the requirement of this part of the code. Probably, this is a linux issue, maybe paypal has changed some server with a newer one and while the older accepted the SOAP request even if it was not with this "compression" parameter, in the newer environment it seems required.
Anyway, everything is back to normality adding this line, we just still have an odd time response (long) for the Pay operation while everyting is smooth for the Preapproval operation but this might depend on different paypal servers managing one or the other operation.