Payment details just stop showing up

Back to this issue, the payment details for transactions after 6/26 are not showing up. is there a process that runs in the background on paypal transactions or does it run to completion in its own thread?

Hi @radjr,

This is probably related to https://www.paypal-notice.com/en/TLS-1.2-and-HTTP1.1-Upgrade/. It’ll most likely require a bit of intervention on the server to update your SSL/TLS libraries (which is beyond OJS’s control).

Regards,
Alec Smecher
Public Knowledge Project

Thanks. These were done on our system on the 29th and 30th. Long after the reports stopped showing up on the 26th.

Hi @radjr,

In that case I suspect you’d be best restoring the “suspicious activity” email template to its default text, per the other thread, as I suspect transaction failures will result in these being sent.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,
How do I track down the failures? We have reset the template and get a bunch of data back including a curl error at the bottom but the transaction completes from Paypal. How does the paypal check for error status?

Thanks!

Hi @radjr,

What is the CURL error?

Regards,
Alec Smecher
Public Knowledge Project Team

Here are the details in file: Some details may need to be redacted so let me know. Thanks.

UPDATED:

Hi @radjr,

I think this got garbled in transmission. The forum uses Markdown syntax, so make sure to use the “code” quoting tool when posting code.

Regards,
Alec Smecher
Public Knowledge Project Team

“code” quoting tool? Blockquote? Preformatted text? Both end up with the same as listed before!

Sorry, this is the only way I could post it.

The Open Journal Systems system is unusual
activity in the functioning of the module
PayPal Payments Journal of Emergency Management.
It may be necessary to further study this
question or manual intervention.

This letter was created by the Open PayPal module
Journal Systems.
Full Request Information:
Array
(
[mc_gross] => 56.00
[protection_eligibility] => Ineligible
[payer_id] => 9AHT26JQ5EJG8
[payment_date] => 07:46:34 Jul 07, 2018 PDT
[payment_status] => Completed
[charset] => windows-1252
[first_name] => James
[mc_fee] => 1.92
[notify_version] => 3.9
[custom] => 4372
[payer_status] => unverified
[business] => radjr@pnpco.com
[quantity] => 1
[verify_sign] =>
Ai3eyH2EJ30Ah0caEWFjHtwmki5NAvCu.I4uCQSUvmWxwh4tsy7MMCOY
[payer_email] => xxx@charter.net
[txn_id] => 6P23921923501072C
[payment_type] => instant
[last_name] => Murphy
[receiver_email] => radjr@pnpco.com
[payment_fee] => 1.92
[shipping_discount] => 0.00
[receiver_id] => YE8SPU9B28X46
[insurance_amount] => 0.00
[txn_type] => web_accept
[item_name] => Purchase of JEM Single Article
[discount] => 0.00
[mc_currency] => USD
[item_number] => 610
[residence_country] => US
[receipt_id] => 1346-5841-5001-8368
[shipping_method] => Default
[transaction_subject] =>
[payment_gross] => 56.00
[ipn_track_id] => 9170150989ad
)

Additional information (if available):
Confirmation return:
CURL error:
Server data:
Array
(
[PATH] => / sbin: / usr / sbin: / bin: / usr / bin
[PP_CUSTOM_PHP_INI] => /var/www/vhosts/wmpllc.org/etc/php.ini
[FCGI_ROLE] => RESPONDER
[HTTP_HOST] => www.wmpllc.org
[HTTP_ACCEPT] => * / *
[CONTENT_TYPE] => application / x-www-form-urlencoded
[HTTP_USER_AGENT] => PayPal IPN (https://www.paypal.com/ipn)
[HTTP_CORRELATION_ID] => 9170150989ad
[HTTP_CAL_POOLSTACK] =>
queueserv-http-qtoc: DaemonChild * CalThreadId = 0 * TopLevelTxnStartTime = 1647535847a * Host = slcnotify8a
[HTTP_CLIENT_PID] => 25091
[CONTENT_LENGTH] => 823
[SERVER_SIGNATURE] => Apache Server at www.wmpllc.org Port
80 </ address>
[SERVER_SOFTWARE] => Apache
[SERVER_NAME] => www.wmpllc.org
[SERVER_ADDR] => 50.63.57.165
[SERVER_PORT] => 80
[REMOTE_ADDR] => 173.0.81.1
[DOCUMENT_ROOT] => /var/www/vhosts/wmpllc.org/httpdocs
[SERVER_ADMIN] => radjr@pnpco.com
[SCRIPT_FILENAME] =>
/var/www/vhosts/wmpllc.org/httpdocs/ojs-2.4.2/index.php
[REMOTE_PORT] => 1062
[GATEWAY_INTERFACE] => CGI / 1.1
[SERVER_PROTOCOL] => HTTP / 1.1
[REQUEST_METHOD] => POST
[QUERY_STRING] =>
[REQUEST_URI] => /ois-2.4.2/index.php/jem/payment/plugin/Paypal/ipn
[SCRIPT_NAME] => /ois-2.4.2/index.php
[PATH_INFO] => / jem / payment / plugin / Paypal / ipn
[PATH_TRANSLATED] =>
/var/www/vhosts/wmpllc.org/httpdocs/jem/payment/plugin/Paypal/ipn
[HTTP_CONNECTION] => close
[PHP_SELF] => /ojs-2.4.2/index.php/jem/payment/plugin/Paypal/ipn
[REQUEST_TIME] => 1530974799
)

Hi @radjr,

Essentially OJS is saying that it tried to contact PayPal to validate the IPN request, but got an empty response. I do suspect that this is related to PayPal’s SSL changes – the dates are awfully close, and I can’t think of anything else that would cause this kind of exchange to fail in the way it has.

I would suggest making sure that your server’s CURL library, both the underlying library and PHP’s support for it, are current.

Regards,
Alec Smecher
Public Knowledge Project Team

Alec,

Remember that the transaction at paypal completed correctly.

I can’t help because I can’t see how you are determining this in the log above. More important it looks like the IPN return notification is not being either sent by paypal or received by OJS.

Please see this response. I think they are related. Is it possible that IPN now requires that a return URL is in the configuration on the paypal side?

The paypal requirement is for TLS 1.2 and HTTP1.1. There is no spec that I have seen specing the curl version which for us is 7.19.7

Alec, we have the same issue. When we go to check this setting in paypal, it reports that the IPN is disabled. When we check the “enable” box and save, the site complains and wants a URL. So the questions are a) are you really using IPN for event notification or b) are you use using the IPN gateway and reading all status during the transaction?

Lastly, are you using IPN notification to trigger sending emails to pay-per-view customers?

Thanks, radjr

Hi @radjr,

Essentially the flow is…

  1. User clicks a “Pay Now” button to go from OJS into PayPal’s website. OJS tells PayPal an IPN URL as part of that button click.
  2. User tells PayPal that they want to pay.
  3. (Server to server.) PayPal contacts OJS via the IPN URL (in #1) and gives it information about the transaction.
  4. (Server to server.) OJS uses that information to contact PayPal and verify that the information it was given is correct. If so, OJS records that the purchase was successful in its own database.
  5. PayPal sends the user back to the OJS website.
  6. When the user tries to view the purchased content etc., OJS will be aware of anything that was successfully purchased and will respond accordingly.

By your record above, the process got as far as step 4, but wasn’t able to confirm with PayPal that it received the right information.

This tells me that the IPN URL is not the issue – the fact that PayPal managed to contact OJS in step 3 means it was correctly used. I’m not sure why PayPal has made this field mandatory.

Regards,
Alec Smecher
Public Knowledge Project Team

Regarding #4, it seems that Paypal sends a confirmation back and it may not occur immediately. So, the questions could be a) Are the return messages being received? b) Are the return transaction IDs the same or are they modified in some way? c) How does that process run in the background and is it possible that the process has terminated some how?

See this faq: https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/#how-it-works

Lastly, does the CURL ssl type need to be hard coded as suggested in other posts?

Thanks! radjr

Hi @radjr,

a) Are the return messages being received?

Yes, they’re culminating in the “investigate transaction” emails you’re seeing.

b) Are the return transaction IDs the same or are they modified in some way?

They are not being modified. I would expect PayPal to return an application-level error message if that were the case.

c) How does that process run in the background and is it possible that the process has terminated some how?

No, the “investigate transaction” email, when sent, is the last thing OJS does in handling those requests.

Lastly, does the CURL ssl type need to be hard coded as suggested in other posts?

This is server-dependent and may work around your situation, but it is a best practice to let the parties negotiate a SSL handshake without specifying unnecessary details.

There are some suggestions for investigating your SSL/CURL library details e.g. here: PAY request returns SSL connect error · Issue #64 · paypal/adaptivepayments-sdk-php · GitHub

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,
Thanks for your patience…

So, where is the code that is determining the “investigate transaction” situation? Seems that is where OJS gives up on the process. And, would we expect OpenSSL or curl to return different data? If it did not connect then it would return NO data correct? thank you.

Hi @radjr,

The condition you’re encountering is implemented here:

Regards,
Alec Smecher
Public Knowledge Project Team

Well I have installed the latest version of CURL and will see if that fixes the problem.

Updated CURL to latest version on server and it seems to work now. No errors on our live tests. For TLS, OpenSSL will be a bit more complicated because the install of openSSL went fine but forcing the system to choice one version to run is a challenge. Still would like to see the difference between the data returned for old version of curl versus new version.

Alec, is there any way to force confirmations on the system so that a user who has paid for the article can actually get access to it? Current, that transaction is in limbo in that PayPal accepted the money but do to comms errors above the transaction did not complete inside OJS. Is there a way to force the completion or set a flat to completion? Thank you!