Jump to content
Sign in to follow this  
coastwatch1

Again: PP Standard - Could not verify the transaction

Recommended Posts

My symptom are like those of thread 397731.  That is, PayPal tells the customer that the purchase has been completed, and sends the customer email to that effect.  PayPal also sends email to the site owner, containing the order details and advising them to process the order immediately.  However, when the customer gets back (via /catalog/checkout_process.php) to /catalog/shopping_cart.php, he sees the error icon gif and the text "Could not verify PayPal transaction.  Please try again."                                                              
 

I have applied what I could learn from that thread, but it has not solved the problem.

 

I'm running osCommerce 2.3.4 with PayPal Payments Standard 3.2, as well as Product in Multiple Categories V2.1 and Theme Switcher 1.4.4, with the DarkHive-Reverse theme.

 

Following the advice in the previous thread, I have done the following:

 

1.  I do NOT specify URLs in my PayPal setup, allowing osCommerce to pass whatever it needs to pass to PayPal, instead.

 

2.  In the setup for the paypal_standard module, I supply the primary email address of the site owner in "Seller E-Mail Address", and leave "Primary E-Mail Address" empty.

 

3.  I reordered 2 lines in standard_ipn.php, according to message 22 of the previous thread.

 

Below is an extract from the log of my web server, suitably sanitized.  (I am the "customer" for this test transaction.)

 

173.0.81.1 - - [08/Dec/2014:17:37:12 -0800] "POST /catalog/ext/modules/payment/paypal/standard_ipn.php HTTP/1.0" 200 - "-" "PayPal IPN ( https://www.paypal.com/ipn )"

 

Below, 99.99.99.99 replaces my actual IP address.

 

99.99.99.99 - - [08/Dec/2014:17:38:56 -0800] "POST /catalog/checkout_process.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iron/35.0.1900.0 Chrome/35.0.1900.0 Safari/537.36"

 

99.99.99.99 - - [08/Dec/2014:17:38:59 -0800] "GET /catalog/shopping_cart.php HTTP/1.1" 200 9269 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iron/35.0.1900.0 Chrome/35.0.1900.0 Safari/537.36"

 

This is followed by the GETs for the other pieces of that page, as you would expect.

 

Here is a sanitized version of the PayPal Standard Debug email:

 

RESPONSE:

 

INVALID

 

Array

{

    [mc_gross] => 5.01
    [invoice] => 10
    [protection_eligibility] => Eligible
    [address_status] => confirmed
    [item_number1] =>
    [payer_id] => *************
    [tax] => 0.00
    [address_street] => ZZZZZZZZZZZZ
    [payment_date] => 17:36:55 Dec 08, 2014 PST
    [payment_status] => Completed
    [charset] => UTF-8
    [address_zip] => 99999-999

    [mc_shipping] => 5.00
    [mc_handling] => 0.00
    [first_name] => ZZZZZZZZZ
    [mc_fee] => 0.45
    [address_country_code] => US
    [address_name] => ZZZZZZ Z ZZZZZZZZZ
    [notify_version] => 3.8
    [custom] => 1
    [payer_status] => unverified
    [business] => example@@Example.com
    [address_country] => United States
    [num_cart_items] => 1     [mc_handling1] => 0.00
    [address_city] => My_city
    [payer_email] => me@@Example2.com
    [verify_sign] => ******************
    [mc_shipping1] => 5.00
    [tax1] => 0.00
    [txn_id] => *****************
    [payment_type] => instant
    [last_name] => ZZZZZZZZ  
    [item_name1] => Test 99997
    [address_state] => CA
    [receiver_email] => example@@Example.com [same as "business" above]
    [payment_fee] => 0.45

    [quantity1] => 1

    [receiver_id] => ZZZZZZZZZZZZZ  

    [txn_type] => cart

    [mc_gross_1] => 5.01
    [mc_currency] => USD
    [residence_country] => US
    [receipt_id] => 9999-9999-9999-9999 
    [transaction_subject] => 1          
    [payment_gross] => 5.01               
    [auth] => 88_random-looking_characters                    
)                                                                                                                                                                                              
Here is the (sanitized) setup of the paypal_standard module:
Version: 3.2 (online status)
Enable PayPal Payments Standard: true
Seller E-Mail Address: examples@@Example.com
Primary E-Mail Address:
Page Style: 
Transaction Method: Sale
Set Preparing Order Status: Preparing [PayPal Standard]
Set PayPal Acknowledged Order Status: default
PayPal Transactions Order Status Level: PayPal [Transactions] 

Payment Zone: --none--
Gateway Server: Live
Verify SSL Certificate: True
Proxy Server:
Debug E-Mail Address: some_address@@Example.com
Enable Encrypted Website Payments: True
Your Private Key: /home/myaccount/.pki/X/Y/zzz-prvkey.pem

<Note X and Y stand for 20-character random alphanumerics, and both directories are mode rwx--x--x. >
Your Public Certificate: /home/myaccount/.pki/zzzzzzzz.pem
PayPals Public Certificate: /home/myaccount/.pki/paypal_cert_pem.txt
Your PayPal Public Certificate ID: ZZZZZZZZZZZZZZZ
Working Directory: /home/myaccount/tmp/paypal/
OpenSSL Location: /usr/bin/openssl
Sort order of display.

 

In the Orders area of the site admin, my purchase appears as follows:

 

Date Added: 12/08/2014 17:37:15

Customer Notified: (a red X)

Status: PayPal [Transactions]

Comments: PayPal IPN Verified [Transaction ID: ZZZZZZZZZZZZZZZZZ;Completed (Unverified; $5.01)]

 

If I understand correctly: the site owner could go ahead and ship the product, update the order status to delivered, etc.  The only problem is that the customer sees a very misleading message: if he actually  does try again, he will wind up having ordered everything twice, and will still get that error message the next time, too.

 

Any suggestions?                                     

 

Share this post


Link to post
Share on other sites

Below, 99.99.99.99 replaces my actual IP address.

 

99.99.99.99 - - [08/Dec/2014:17:38:56 -0800] "POST /catalog/checkout_process.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Iron/35.0.1900.0 Chrome/35.0.1900.0 Safari/537.36"

Is there only 1 such entry for checkout_process.php in your log file or are there perhaps two occurring at the same time or within 1 second of each other?


:heart:, osCommerce

Share this post


Link to post
Share on other sites

A further thought on my problem: at https://developer.paypal.com/webapps/developer/docs/classic/ipn/integration-guide/IPNIntro/, the description says "Your listener HTTP POSTs the complete, unaltered message back to PayPal; the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message."  If what you send back to PayPal is not what was sent, you get the "INVALID" that I am seeing, rather than "VERFIED".  I find the description slightly unclear, but it appears to say that if PP sent you a ":" encoded as %3a, and you send back %3A, or vice versa, that might be enough to trigger the "UNVERIFIED".  Likewise if PP sent a space encoded as %20, while osCommerce, since it uses PHP's urlencode(), encodes spaces as +, might trigger my problem.

 

Of course, that leads to the question of why I am having this problem, while plenty of other osCommerce istallations have no such trouble.  Thus, I am likely to be barking up the wrong tree.

 

Can anyone suggest a way to see exactly the text sent after the "?" in both directions, so I can look for signs of that problem, caused by the not fully specified nature of urlencoding.  Or can someone confirm for me that what I describe is never a problem between osCommerce and PayPal Standard?

 

The debug message shows the results of urldecode() of what PP sent, the middle stage of the process, while I want to see what the URL parameters look like before that call, and after the urlencode().

 

Thank you.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×