Jump to content
Sign in to follow this  
devosc

PayPal_Shopping_Cart_IPN

Recommended Posts

Hi there, I saw a question about COULD NOT PROCESS email in another thread, which in that case occred becasue of the cart total did not match, I think Radders tried to point this out before, but I was thinking of it being due to something else, below is what I suggest is the cause and solution:

Hi All,

 

I have a problem with the latest Paypal 1.5 contribution. I have the e-mail notification set to DEBUG. the first e-mail looks fine - DEBUG subject with all the fields completed. The second e-mail looks ok too with the sender as the customer and all details are correct. The third e-mail with the subject VERIFIED is again ok as well as the fourth e-mail with subject email_receiver. the problem starts with the fifth e-mail - check_valid_payment which has the message 'Incorrect Cart Total' and the sizth and final e-mail with subject cart says: COULD NOT PROCESS: You have received a payment of 114.50 USD.

The customer is then not directed to the checout_success.php page although the order has been paid and the order is not entered into the database and the basket is retained. Anyone any ideas??

 

Also, I need to include the giftwrap total amount from the giftwrap contribution. This is not sent to paypal, I guess I would need to add this to the goods total and display it as a separate item in the items basket. Any suggestions??

 

Thanks for your help.

Hi there,

 

It has now occured to me that a problem with the incorrect cart total could be because the osC cart's total can have more than two decimal places.

So when PayPal sends you the mc_gross figure in 2 decimal format, these two figures might not match due to decimal precision, this I suppose would of been nice to confim if that email had told us what to numbers it was currently comparing.

 

A solution would be to ensure that numbers provided to paypal are rounded to 2 decimal places. Then when comparing these numbers we make sure they are both in two decimal place formats.

 

I don't currently have the time to iron this out.

 

I am however intrigued, in that the customer was not redirected to checkout_success, and that the cart items still remained.

If the transaction was verified by PayPal and the transaction already recieved the customer is redirected to checkout_success and the contents of their cart reset.

If the transaction was verified by PayPal but not already recieved then they are allowed to continue checking out as per osC default.

If the transaction was 'not' verified by PayPal then the customer is still allowed to continue checking out as per default osC and you would also get an email letting you know that particular customer's transaction was not verified.

 

When you said the customer was not redirected to checkout_process, then were did actual go (end up)? because upon return osC will push them along the checkout process untill they reach checkout_process, i.e if they returned to site and the carts contents 'was' empty then the customer would have arrived at the 'whats in your cart page', but since the shipping, payment and confirmation sections would of been completed prior to going to the PayPal site upon return and if the contents of the cart was 'not' empty then the only other thing left is checkout_process which as stated above all ways allows the customer to proceed to checkout_success.

 

This question would of been better posted in the contribution support thread.

A quick fix, 'might' be, to change (in catalog/includes/classes/paypal/cart.php)
 $ipn->key['mc_gross']

to

number_format($ipn->key['mc_gross'],2)

This should probably be ok for the aggregate cart method, not sure about Method 2 but my feeling at this time is that it should now be ok too.

Please let us know if you have any further thoughts on this issue.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

The above should be

$cart->show_total()

to

number_format($cart->show_total(),2)

Which occurs in the function valid_payment in catalog/includes/classes/paypal/cart.php.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

A thought has just come across my mind about how PayPal might calculating the gross total, for example suppose in the osC you had the following

 

sub total = 0.007

shipping = 0.007

 

osC total = 0.014

 

BUT I suspect that our friend PayPal will actually calculate it as follows

 

sub total = 0.01

shipping = 0.01

 

PayPal total = 0.02

 

Hence PayPal's 2 decimal rounding plagues again.

 

Untill this can be further confirmed, tested, etc, you might want to just comment out that particular if statement in the cart.php file. At least this way the order is stored, and since you should always verify the payment in your PayPal account anyway, you should be ok (maybe as long as your terms and conditions forces them to agree that you the store owner are allowed to refuse any transactions etc).

 

What those checks in cart.php do is to try to ensure that the IPN it recieves pertains to relevant data (i.e. what is in that customer's shopping cart), because anyone could make/post a PayPal payment to your account, which via the IPN could register it as an order. Hence these checks are supposed to throw out spoof/hoax transactions.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Actually Greg I'm trying to determine whether in my case it is the rounding or the fact that I had my catalog set to SSL. Anyway I have followed the instructions at the beginning of the support thread and changed that setting in catalog/includes/configure.php

Tests are now working, but again I await more real transaction through the module.

 

The symptoms on the customer side were a 'not found' error on returning to my site at checkout_process.php which went away if the customer refreshed the page but still didn't return them to the confirmation page

Share this post


Link to post
Share on other sites

Hi Greg,

 

Thanks for te work on thecontrib.

 

I have installed v1.5 on MS2 and all is working well (Paypal payments being made and email notifications arriving) however I have 2 small glitches and would appreciate your help (or pointer as to which bi of code to investigate).

 

1. When buyer gets returned to my site to checkout_success.php all the see is a blank page! (The proper checkout_success.php page is displayed when making payment via another method).

 

2. Probably linked to above is the fact that the items purchased are not removd from the cart.

 

3. Customer orders in OSC Admin are not added to IPN section. (Again working fine for other orders).

 

Any help greatly appreciated.

 

Thanks,

 

Mike.

Share this post


Link to post
Share on other sites

Aoplogies but it's not checkout_success but checkout_process they get directed to. Should I guess then be sent to checkout_success . . . . . .

Share this post


Link to post
Share on other sites

This 'incorrect cart contents' problem is still ongoing having made the following recommended change:

 

number_format($cart->show_total(),2)

 

I do not believe that this is a problem with decimal points as my Os is set to 2 decimal places only. I cannot act as a live customer and see where the page leads to having confirmed payment with Paypal as this will require credit card details and process payment. Anyone know how to test this without proccessing payment?

Share this post


Link to post
Share on other sites

I just made another trial purchase, I have a local server where all my products are $0.01, I chose one product and checked out using the Method 1 (aggregate). Upon confirmation I was directed to the PayPal site, I logged in and payed the $0.01, before clicking the continue button I went to osC admin to see if the IPN had arrived, it had. I then clicked continue and was redirected to /catalog/checkout_process.php which determined that I had a qualified transaction and that it had already been processed, I was then redirected to checkout_success.php and the contents of my shopping cart was cleared.

 

In my PayPal account I have the IPN url specified to use SSL, i.e. httpS://

 

At present in osC admin / Sessions all of the settings are currently flaged to false. Whether changes in these default settings, for example recreate session, are causing these unkown results to occur I am not sure at present.

 

May be I need to try and mimick a real purchase, but right now I still have to find out where all my pennies are going in developing this contrib, PayPal says they have been refunded but they haven't appeared in back in the originating accont.

 

checkout_proccess.php is the correct file to be returing to.

 

Ah, ok, I now see that the email regarding 'Incorrect Cart Contents' is actually an occurance of when the number of items in the shopping cart does not match the number specified by PayPal which is their 'num_cart_items' variable which only tested/compared when the store owner is using the Method 2 (itemized) PayPal shopping cart.

 

I now just test a purchase of 2 products each @ $0.01 and the whole process was successful, as in the same above Method 1 case.

 

At this moment in time it is unclear as to whether integrating this contrib/module into your existing site that may have contribs may be causing a conflicts.

 

You should always be redirected to checkout_process upon clicking the PayPal continue button. To confirm this, prior to clicking 'your' checkout confirmation button, view the source of that page, and find the hidden field called 'return'.

 

As said the code in the paypal payment module allways allows the checkout_process.php file to continue processing if the PayPal - osC IPN has not already been received, which if you look at the bottom of checkout_process.php you will see

$cart->reset(true);
// unregister session variables used during checkout
tep_session_unregister('sendto');
tep_session_unregister('billto');
tep_session_unregister('shipping');
tep_session_unregister('payment');
tep_session_unregister('comments');

tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));

So the customer's cart is always reset (cleared) and they are redirected to checkout_success.php

 

That same snip of code is what is used when the PayPal - osC IPN has already been received (which creates implicitly creates the order). So when the customer returns to the site the above snippet of code (which can also be found in the paypal payment modules before_process function) simply clears the cart and redirects the customer to checkout_success.php and there will be 'paypal=authorized' appended to the URL.

 

Earlier in this thread I outlined a procedure on how to Test your IPNs.

 

As you can see PayPal passes back via the IPN a good few parameters, each has their own purpose and to that end it has not been possible to fully cover the each aspect of the transactions IPN info.

 

So when you recieve payments via the 'web_accept' and 'cart' methods provided that the IPN is authentic from PayPal, the last set of checks made of the transaction is whether it is a valid payment which is called in catalog/ipn.php and the code for this function, valid_payment(&$ipn,&$cart,$currency), is in classes/cart.php.

 

If you would like you could easily just remove the conditional statement in catalog/ipn.php

    if ($ipn_cart->valid_payment($ipn,$cart,$currency) ) { //needs work
     $description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart";
     if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n");
     unset($description);
     $ipn->insert_ipn_txn();
     $ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id());
   } else {
     if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"COULD NOT PROCESS: You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n");
   }

and change it to

$description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart";
if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n");
unset($description);
$ipn->insert_ipn_txn();
$ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id());

It would be nice to of been able to better determine the cause for this particular problem, but I am unable to quickly replicate it, maybe you could try and edit the email that is sent to you to provide you with the values of the variable s that the test is failing on, anf the type of transaction ('web_accept','cart').

 

The problem about returning to a blank screen is unkown to me at this time. According my trial purchases I do not have this problem at all.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

All my test purchases are successful but my live purchases fail to appear in the orders table because of 'Incorrect Cart Total'. The differences between the test and live transactions are that the live transactions are for larger amaounts, include more than one item and originate from overseas so have a shipping cost. Could it be the shipping cost that is the problem ?

Share this post


Link to post
Share on other sites

If you are able to make a real test PayPal transaction, another test that you try, is to temporarily rename catalog/ipn.php to say 'catalog/ipn.phpX' that way PayPal will not be able to send the IPN, now when you click PayPal's continue button you will then see what would happen if the Customer returned and the PayPal - osC IPN had not already been received, i.e checkout_proccess will then actually be used to generate the order, and you will be redirected to checkout_success.php as usual (in this case you will not see 'paypal=authorized in the url'). Now check osC admin, the IPN should be there. Remember to rename the ipn.phpX back to its original name afterwards!

 

Radders I have just seen your msg, until such time this can be fully resolved it might be easier to do as suggested and just reomove the check_vaild_payment clause form catalog/ipn.php, this way you will get the transaction, and upon your personal verfication, you can always complete the order as usual or just delete if neccessary.

 

Guys (and Gals), I can't give much more of my time for free!


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hi Greg,

 

Many thanks for this great Paypal contribution. You have obviously put a lot of work into it and it is a definite boon for all present and future Paypal processed oscommerce websites. I would like to see what is causing this 'incorrect cart contents' myself and possibly contribute to resolving the problem with getting the checkout_success.php file when returning from the Paypal site. I cannot checkout with an amount of less than $5 and I don't want Paypal to sting me for this when I am only testing. Turning IPN to test doesn't turn off card payment, it just turns off the notification as far as I am aware. Does Paypal have test Visa card number like 4111-1111... which is accepted as a test?

Share this post


Link to post
Share on other sites

Hi MS,

 

No I don't think paypal has such a feature.

 

The best I think we could could do is to try an replicate the transaction by amending the ipn_test.html file to suit, i.e at present I think that it only has fields for one item, maybe two. You could try, or if you post here the IPN info, specifically the numerics etc, the id's aren't important, I could try too.

 

Basically you just amend the ipn_test.html file to suit, get it to point to catalog/ipn.php, in osC admin set it to Test Mode. submit the ipn_test.html form. This will store the transaction irrespectively, but you will get emails of the failed test results etc.

 

In particular, for check valid payment the emails are:

 

Incorrect Cart Contents => No of items in cart did not match when the transaction was a 'cart' method, i.e you are itemizing your cart contents on PayPal as well

 

Incorrect Cart Currency => the currency chosen at checkout time does not match the currency the customer paid in.

 

Incorrect Cart Total => The shopping cart's total does not match the 'mc_gross' figure provided by PayPal.

 

-----------------------------------

 

Now to look into checkout_process.php, you could spoof / hijack the checkout process, basically go through and checkout, but do not click 'your' confirmation button which would take you to PayPal, instead, look in your URL for the osCsid, i.e. if the customers shopping cart session id, if it is not there, view the source of the page, scroll down and find the hidden custom variable, it's value is the osCsid. (You will also see the list of items that are specified in the cart)

 

Copy the osCsid, open another browser window. In that url address bar type catalog/checkout_process.php?osCsid=***************

Replace the ***** with the value of the osCsid you just copied. Now hit the return key.

Should now be then redirected to checkout_success.php. You will also get email warning you that you have just hijacked the checkout proceedure.

 

This might not be the right test, but it might give an idea of whats happening, because really there should be no reason for it too show a blank screen, something is casuing it to die/exit prior to the checkout_success.php redirect. Out of interest what other contributions do you have installed?

 

In fact I think it should be possible to combine both of the above to really mimick a 'real' transaction if you see what I mean. Since the ipn_test.html is supposed to be the fields that PayPal would post back to your site in their IPN. So just get the form to post to catalog/ipn.php and for that form's action append the osCsid in the url specified as discussed above.

Edited by gregbaboolal

"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Thanks Greg,

 

I will try your suggestion. I have the giftwrap contribution installed as well and this comes up as a subtotal when selected but is not forwarded to Paypal. Is there any way to include that if selected? Would I need to merge it to the cart total before sending it to Paypal or can Paypal list it separately as it does packing?

 

Thanks again.

Share this post


Link to post
Share on other sites

Hi Greg,

 

Tried your suggestion - used OsCsid with the checkout_process.php and got a blank page too!! Something is causing the checout_process.php page not to redirect to checkout_success.php. I entered checkout_success.php in the browser along with the OsCsid and that worked fine. Any ideas?

Share this post


Link to post
Share on other sites

In case you are worried about all those pennies that you have to pay Paypal when you are testing I have noticed that the fee for these transactions is -.01 .

The next result is free and your balance is not affected!

Share this post


Link to post
Share on other sites

Yes - the remainder of checkout_process.php after the customer is returned from the Paypal website is not processed. No e-mail is sent to customer or store owner and no order number or or table entry is generated. Even the paypal_ipn table is not completed when a user has made a proper purchase. I believe my users are getting redirected back to a blank page with the checkout_process.php page in the browswer address just I am albeit in a test. So what is causing the whole process to abandon the remainder of checkout_process.php?

Share this post


Link to post
Share on other sites

Very wierd . . . .

 

Everything is now working exactly as it should . . .

 

This morning I got an error when transferring from OsC to Paypal saying that there was an error with the sellers (my) email address. I investigated and found no problems. What I have done however is to change OsC Admin - Modules - Payment - Paypal - Business Name from my business name to its email address as registered with Paypal.

 

The result of this change was that everything is now working perfectly. I guess at some point this Business Name is passed to Paypal for verification and in my case the match needed was an email address.

 

Anyhow, I don't suppose this will help anyone else but if it does - great.

 

Thanks Greg for the contrib and help. :)

 

Mike.

Share this post


Link to post
Share on other sites

OK, Ithink I now know what is causing the blank screen, in catalog/includes/classes/paypal/ipn.php the class constructor has some 'exit' terms which is causing the the application to terminate.

So if you remove the 'exits;' form that section of code you will be allowed to checkout.

 

However! It should be noted that those exit statements occur, when [A] The transaction type is not one in PayPals verification version 1.5 list, i.e web_accept, cart, send_money and reversal, and if 'A' is ok but the 'txn_id' is not of the same length as PayPal specifys in their version 1.5 verfication scheme.

 

I haven't gone through all the precautionary tests, but if you remove those exits you should now be ok, maybe somebody could check this by first renaming catalog/ipn.php to ipn.phpX so that PayPal cannot send their IPN prior to the customer returning to the site. Another trial transaction should then be made, and before clicking the continue button have a look in osC admin for the IPN, hopefully it should be there, then click the continue button and see what happens.

 

Incidently when noticing this, I also received an email with the subject 'unkown transaction type' for .

 

Out of interest if you did recieve a valid PayPal payment could you please check that trnsaction details and let me know if the number of characters in the transaction ID (# .....) is not 17 characters in length.

 

Please do keep us inform whether or not this resolves the issue. When I have the time and mind I will look to see what risks this might have to a transactions authenticity, more importantly why it is occuring.

 

Didn't any you get the unkown 'transaction type' or 'unkown post' ?, the latter only really occurs when there is absolutely no information at all.

 

Sorry JimJam, when I set up the install module side I used Business Name instead it should of read Business ID which is what PayPal meant.

 

  function paypal_ipn($email,$post_vars='',$session_id,$debug='0') {
   $this->_debug_email = $email;
   $this->_debug = $debug;
   $transaction_list = array('web_accept','cart','send_money','reversal'); //accepted transactions
   if ( !$this->_valid_trans_type($post_vars['txn_type'],$transaction_list) ) {
     if ($this->_debug) $this->send_email('unkown transaction type',"I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?");
     exit;
   } else if(strlen($post_vars['txn_id']) == 17) {
     //Looks like a PayPal transaction
     $this->_init($post_vars,$session_id);
   } else {
     if ($this->_debug) $this->send_email("unkown post","I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?");
     exit;
   }
 }

the above should now be

  function paypal_ipn($email,$post_vars='',$session_id,$debug='0') {
   $this->_debug_email = $email;
   $this->_debug = $debug;
   $transaction_list = array('web_accept','cart','send_money','reversal'); //accepted transactions
   if ( !$this->_valid_trans_type($post_vars['txn_type'],$transaction_list) ) {
     if ($this->_debug) $this->send_email('unkown transaction type',"I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?");
   } else if(strlen($post_vars['txn_id']) == 17) {
     //Looks like a PayPal transaction
     $this->_init($post_vars,$session_id);
   } else {
     if ($this->_debug) $this->send_email("unkown post","I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?");
   }
 }


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hello

 

I'm running live test with my wife's paypal account.

 

The purchase process - no errors except:

 

If I from admin chose shopping cart method 1 (Aggregated) paypal want me to pay the total costs except shipping costs ??? :(

 

If I chose 2 (Itemize) paypal wan me to pay the correct amount with the shipping costs specified correctly.

 

When the payment I got the following e-mails in email mode 2:

 

1. Cornelius Hansen & Co. PayPal IPN: email_receiver

 

The configured email_receiver is: a@a.dk

The configured business ID is a@a.dk

PayPal says

reciever_id=a@a.dk , business=a@a.dk

(anonymized by me - a 4 are identical in the real e-mail)

 

2. Cornelius Hansen & Co. PayPal IPN: DEBUG

all the details from the order.

 

3. Re: Cornelius Hansen & Co. PayPal IPN: VERIFIED

 

Connection Type

curl= socket= domain=www.paypal.com port=

#####################

VERIFIED

 

4. Cornelius Hansen & Co. PayPal IPN: insert_ipn_txn

 

IPN 67 has been inserted

 

5. Cornelius Hansen & Co. PayPal IPN: DEBUG

looks like all the order details again

 

6. Cornelius Hansen & Co. PayPal IPN: VERIFIED

 

Connection Type

curl= socket= domain=www.paypal.com port=

#####################

VERIFIED

 

7. Cornelius Hansen & Co. PayPal IPN: check_valid_payment

 

Incorrect Cart Total

 

8. Cornelius Hansen & Co. PayPal IPN: cart

 

COULD NOT PROCESS: You have received a payment of 24.38 USD

 

 

Comment by me: The amount is correct.

 

I can't complain. I get no blank screen - the check out success is working fine.

 

I get a lot of e-mails

 

BUT I DON'T GET ANY INP DATA INTO MY OSC SYSTEM - WHY?

because of mail nr. 7 - why is the cart total incorrect when the amount is correct?

 

I do not hope this is a stupid question. :wacko:

Please help

 

Cornelius


dog1.jpg Who let the dog out ?!!! Newer trust a smiling dog!

Share this post


Link to post
Share on other sites

I shoul have mentioned:

 

I have instaled the eBay Auction Manager contribution 1.0

 

In the instal instructions there's written:

 

******* NOTE FOR USERS of other payment modules ***********

 

SEARCH IN YOUR PAYMENT MODULES FOR:

 

$payment_modules->after_process();

 

 

Add ONE OF THE FOLLOWING Calls:

 

1. If you have access to the order ID, then add the following:

---------------------------------------------------------------

 

//+++AUCTIONBLOX.COM

$cart->reset(true, $order_id); // WHERE $order_id == the order ID

//+++AUCTIONBLOX.COM

 

 

2. If you do NOT have access to the order ID, then add the following (or verify that it already exists):

---------------------------------------------------------------

 

//+++AUCTIONBLOX.COM

// This will set the state of the auction sale to checked out, but DOES NOT set

// the order ID on the auction sale. This is only necessary to be able to click

// the "View Order" link in the Sales:Checked Out" screen, but it is not that

// important, because you can manually go to the orders screen and see the order.

 

$cart->reset(true);

 

//+++AUCTIONBLOX.COM

 

The problem is that I can't find $payment_modules->after_process(); anywhere in this contrib?

 

Cornelius


dog1.jpg Who let the dog out ?!!! Newer trust a smiling dog!

Share this post


Link to post
Share on other sites

Cornelius,

 

Please read the last few pages of the thread a suggested solution has been previously posted.

 

the after_process() is in catalog/modules/payment/paypal.php

Hint: you will also need to define $cart global in the function, see the before_process() in that file for an example.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites

Hello Greg

 

I'm terible sorry - I don't understand the answer. As I see it is there several suggested solutions in the last few pages - could you please point it out for me?

 

the after_process() is in catalog/modules/payment/paypal.php

Hint: you will also need to define $cart global in the function, see the before_process() in that file for an example.

 

I just don't understand it - I was looking for $payment_modules->after_process(); please explain - I have used hours with this and I want it to work. I would hate to downgrade to version before 1.0 in order to get it work.

 

Could you please explain this to:

 

If I from admin chose shopping cart method 1 (Aggregated) paypal want me to pay the total costs except shipping costs ???

 

If I chose 2 (Itemize) paypal wan me to pay the correct amount with the shipping costs specified correctly.

 

When the payment I got the following e-mails in email mode 2:

 

Sincerely

Cornelius


dog1.jpg Who let the dog out ?!!! Newer trust a smiling dog!

Share this post


Link to post
Share on other sites

C,

$payment->after_process(); is 'called' in checkout_process.php and for this contribution it is 'defined' in catalog/includes/modules/payment/paypal.php.

I just made another trial purchase, I have a local server where all my products are $0.01,  I chose one product and checked out using the Method 1 (aggregate). Upon confirmation I was directed to the PayPal site, I logged in and payed the $0.01, before clicking the continue button I went to osC admin to see if the IPN had arrived, it had. I then clicked continue and was redirected to /catalog/checkout_process.php which determined that I had a qualified transaction and that it had already been processed, I was then redirected to checkout_success.php and the contents of my shopping cart was cleared.

 

In my PayPal account I have the IPN url specified to use SSL, i.e. httpS://

 

At present in osC admin / Sessions all of the settings are currently flaged to false. Whether changes in these default settings, for example recreate session, are causing these unkown results to occur I am not sure at present.

 

May be I need to try and mimick a real purchase, but right now I still have to find out where all my pennies are going in developing this contrib, PayPal says they have been refunded but they haven't appeared in back in the originating accont.

 

checkout_proccess.php is the correct file to be returing to.

 

Ah, ok, I now see that the email regarding 'Incorrect Cart Contents' is actually an occurance of when the number of items in the shopping cart does not match the number specified by PayPal which is their 'num_cart_items' variable which only tested/compared when the store owner is using the Method 2 (itemized) PayPal shopping cart.

 

I now just test a purchase of 2 products each @ $0.01 and the whole process was successful, as in the same above Method 1 case.

 

At this moment in time it is unclear as to whether integrating this contrib/module into your existing site that may have contribs may be causing a conflicts.

 

You should always be redirected to checkout_process upon clicking the PayPal continue button. To confirm this, prior to clicking 'your' checkout confirmation button, view the source of that page, and find the hidden field called 'return'.

 

As said the code in the paypal payment module allways allows the checkout_process.php file to continue processing if the PayPal - osC IPN has not already been received, which if you look at the bottom of checkout_process.php you will see

$cart->reset(true);
// unregister session variables used during checkout
tep_session_unregister('sendto');
tep_session_unregister('billto');
tep_session_unregister('shipping');
tep_session_unregister('payment');
tep_session_unregister('comments');

tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL'));

So the customer's cart is always reset (cleared) and they are redirected to checkout_success.php

 

That same snip of code is what is used when the PayPal - osC IPN has already been received (which creates implicitly  creates the order). So when the customer returns to the site the above snippet of code (which can also be found in the paypal payment modules before_process function) simply clears the cart and redirects the customer to checkout_success.php and there will be 'paypal=authorized' appended to the URL.

 

Earlier in this thread I outlined a procedure on how to Test your IPNs.

 

As you can see PayPal passes back via the IPN a good few parameters, each has their own purpose and to that end it has not been possible to fully cover the each aspect of the transactions IPN info.

 

So when you recieve payments via the 'web_accept' and 'cart' methods provided that the IPN is authentic from PayPal, the last set of checks made of the transaction is whether it is a valid payment which is called in catalog/ipn.php and the code for this function, valid_payment(&$ipn,&$cart,$currency), is in classes/cart.php.

 

If you would like you could easily just remove the conditional statement in catalog/ipn.php

    if ($ipn_cart->valid_payment($ipn,$cart,$currency) ) { //needs work
     $description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart";
     if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n");
     unset($description);
     $ipn->insert_ipn_txn();
     $ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id());
   } else {
     if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"COULD NOT PROCESS: You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n");
   }

and change it to

$description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart";
if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n");
unset($description);
$ipn->insert_ipn_txn();
$ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id());

It would be nice to of been able to better determine the cause for this particular problem, but I am unable to quickly replicate it, maybe you could try and edit the email that is sent to you to provide you with the values of the variable s that the test is failing on, anf the type of transaction ('web_accept','cart').

 

The problem about returning to a blank screen is unkown to me at this time. According my trial purchases I do not have this problem at all.


"Any fool can know. The point is to understand." -- Albert Einstein

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×