Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

PayPal_Shopping_Cart_IPN


devosc

Recommended Posts

PayPal_Shopping_Cart_IPN

 

logo3.gificon_visa.gificon_mastercard.gificon_discover.gificon_amex.gificon_echeck.gificon_switch.gificon_solo.gif

 

Instant Payment Notifications

 

Overview

Allows the store owner to choose between sending an aggregate cart total to PayPal or to upload the cart on an individual item basis that then enables the customer to also view the contents of the cart whilst on the PayPal site.

 

Utilizes PayPal's Instant Payment Notification to automatically update the store's database.

 

IPN transactions can then be viewed in the osC admin section along with it's corresponding order.

 

Benefits

There is probably at lot more potential available here, but initially, apart from knowing the status of a PayPal payment, it can also allow you to compare your customers Name and Address registration details to what they themselves have registered (and verified where applicable) with PayPal.

 

This thread is a continuation of it's Contribution Announcement. The contribution itself is available here.

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

Link to comment
Share on other sites

  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Hi Radders,

 

In /catalog/admin/orders.php the main addition made was to insert an if statement to check whether the payment is via PayPal, this occurs where the ENTRY_PAYMENT_METHOD title is displayed and if it is a PayPal payment then the file, paypal_ipn_order.php is included. The only other two changes made to the admin/orders.php file were for the 'back' button links, which checks if the payment method is paypal and that the $HTTP_GET_VARS['refer'] is equal to 'ipn' this enabled redirecting back to the list of PayPal IPN's rather than the list of orders which is the default case.

 

A search for 'paypal' in the common osC files affected by this contribution will show the insertions made, if that helps any :). If I can recall correctly, apart from admin/orders.php and catalog/checkout_process.php (which has a single line insertion), the rest are just english text, filename and database table names definitions.

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

Link to comment
Share on other sites

Hi susie,

 

to upgrade from v1.4, if possible just copy everything again to the catalog folder with the exception of checkout_process.php, filenames.php, database_tables.php, any of the language files, and admin/boxes/customers.php.

 

v1.5 removed the possibility of a 'Completed' order being stored in the paypal_ipn database table even though it may not actually satisfy the check to see whether it is a vaild payment, i.e do the cart totals match, are the currencies the same, and are the gross totals the same.

 

That revision now enables the ease of further development and/or constraints prior to storing the 'ipn' transaction in the database. Previously in v1.4 when checking to see wether the ipn transaction is unique, it was being automatically stored if it did not already exists.

 

I am not sure why you're not receiving emails, you should get at least one or two, but if you set the notification level to 2 should definately get a DEBUG email.

 

Let me know if you are still not receiving any emails. You could set to Test Mode = 1 in osC admin, and try posting to the ipn.php file using ipn_test.html found in the samples directory, that should at least generate some info, but, if I can recall, it will also populate database tables but you should then be able to delete it as a normal order (just put something in the memo field so you can identify it).

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

Link to comment
Share on other sites

Hello again,

 

I have tried the test.php and am given this:

 

Connection NOT working

Warning: fclose(): supplied argument is not a valid File-Handle resource in /home/virtual/site14/fst/var/www/html/catalog/test.php on line 8

 

Seems there is a comms problem, could this be due to fsocket and fclose etc not being installed?

 

Thanks for all your help

 

Duncan

Link to comment
Share on other sites

Right first off - I had IPN V0.981 installed. No joy with it. Couldn't get it to work whatsoever.

 

Installed this new IPN module. Worked first time. Am overjoyed.

 

Just a few problems I have

1. it didnt change my order's status to the type I defined in the admin screen (order still says "pending" and not "paypal confirmed". Does it need to be set to anything else to start with in order for that change to be effected?

 

2. The fields it sent to paypal could be changed slightly to make things a bit more helpful. Can you change item_number to the the OSC order number? And item_name to be what item_number is now?

 

3. I got duplicate IPN transactions come through - obviously the second lot were flagged as invalid.

 

4. The order email that OSC sends out no longer makes reference to the method of payment used by the customer, can this be added back in?

 

Apart from that I can only say a massive thank you - I had been worried about running my store with a half-working paypal module but you've come up with the solution. Great start to 2004!

 

Cheers

Bill

Link to comment
Share on other sites

Hi Bill,

 

I'm glad you like it.

2. The fields it sent to paypal could be changed slightly to make things a bit more helpful. Can you change item_number to the the OSC order number? And item_name to be what item_number is now?
When developing this contrib I adhered strictly to osC's methodology for processing PayPal payments.

This is why it is more secure than IPN_v0.981, because PayPal receives the transaction information via the POST method, where as IPN_v0.981 uses the GET method which places the transaction details in the URL (address bar) of the customers browser (thus potentially allowing them to change the price etc...).

The reason why IPN_v0.981 'had' to redirect the customer via the GET method was, for example, to enable storing the customers order, which consequently generated a new 'order_id' that could then be passed to PayPal to show on their site/invoice.

But, as said, in order to safely transfer the transaction details to PayPal the POST method must be used, but (to my knowledge) this can only occur when the customer hits 'your' checkout confirmation button which immediately directs the customer to PayPal with all of the information available at that point in time.

Now, a possible solution, would be to have a seperate paypal_orders table (the current table of that name is used in a different context) where a potential transaction number could then be generated from, or indeed an order (as such) could be generated such that it would enable the generation of an 'order_id' and when the transaction is actually 'Completed' (etc) the pertaining information is inserted into that reserved spot.

Thinking, quickly, now, it probably wouldn't be a good idea to directly use the 'orders' table to do this otherwise you could end up with blank orders showing in osC admin, thus a work around would be required using the 'paypal_orders' table.

So at present it is not possible to pass the order number to PayPal as the item_number.

 

I will look into changing the item_name to list the items being pruchased instead of the the item_number. However given the above what would you suggest to be placed into item_number (which is an optional parameter and could be left out altogether).

 

It is also possible to specify your own 'invoice' number, which the customer will not see or be able to edit, but must be unique per transaction.

 

You'd might like to look over the IPN parameter options available which can be found in the PayPal IPN Manual, in relation to the nature of your business, which includes auctions and subscriptions. There is also available PayPal's Shopping Cart Manual.

 

1. it didnt change my order's status to the type I defined in the admin screen (order still says "pending" and not "paypal confirmed". Does it need to be set to anything else to start with in order for that change to be effected?
This is a reminiscent feature of PayPalIPN_v0.981.

As noted above I strictly adhered to osC's default methodology. And at present this contribution will only accept an IPN from PayPal when the transactions payment_status is 'Completed'. However should the customer click the last PayPal continue button and return to your site the order is completed as per default osC, however you will get an email if the at that moment in time, upon the customer's return, their transaction could not be verified by PayPal - which may be due to a communications error (unlikely) or if the person is trying to fool with the payment system (i.e. hack/hijack it) - you will receive an email with the customers id, first and last name, to that effect.

So at present, I have not made any changes to osC as to how it regards reciept of a PayPal payment, i.e. it will just say pending, but when looking at the customers order and pertaining PayPal transaction information you will be able to see the payment_status - which will be 'Completed' if recieved via the independent PayPal - osC IPN, and whatever the payment status is if the customer returned to the site, i.e it might well be 'Pending', 'Failed', or 'Denied', there are two other types in this category 'Refunded', and 'Cancelled', which may occur but, quickly thinking, I cannot envisage a customer returning to your site in either of those two states.

This might now suggest that a 'Pending' status should also be allowed to be registered via the PayPal - osC IPN (i.e. the one PayPal sends independently to your site - which I suspect is always sent prior to PayPal showing the customer their last PayPal page - where the customer would click the contiue button to return to your site).

These instances can be easily accommodated but requires a little more scripting to potentially find and update the corresponding PayPal transaction.

Thus at present it is left up to you the store owner to manually determine and update an osC order from 'pending' to 'processing'.

3. I got duplicate IPN transactions come through - obviously the second lot were flagged as invalid.
If you are happy that the contribution is operating to your satisfaction - set the email notification level in osC/Modules/Payment/PayPal to level 1, this will reduce the number of emails received per transaction.
4. The order email that OSC sends out no longer makes reference to the method of payment used by the customer, can this be added back in?
Thanks, I hadn't noticed this, this is ocurring because the independent PayPal - osC IPN is being recieved prior to the customers arrival, and although the independent case uses exactly the same script as checkout_process.php but located elsewhere (in /catalog/includes/classes/paypal/cart.php) the conditional statement that printed the payment method was not being evaluated as true, to fix this at the bottom of cart.php the bit where it says:
  if (is_object($$payment)) {
   $email_order .= EMAIL_TEXT_PAYMENT_METHOD . "\n" .
                   EMAIL_SEPARATOR . "\n";
   $payment_class = $$payment;
   $email_order .= $payment_class->title . "\n\n";
   if ($payment_class->email_footer) {
     $email_order .= $payment_class->email_footer . "\n\n";
   }
 }

can be replaced with:

  $email_order .= EMAIL_TEXT_PAYMENT_METHOD . "\n" .
                 EMAIL_SEPARATOR . "\n";
 include(DIR_WS_LANGUAGES . $language . '/modules/payment/paypal.php');
 $email_order .= MODULE_PAYMENT_PAYPAL_TEXT_TITLE . "\n\n";

Incidently, in the Contributions Announcement thread I mentioned the possibility to have a third option in osC admin which would assign Method 2 (Itemized cart) to be used as the default method of transferring the osC cart information to PayPal however if that particular transaction required tax to be be charged it would automatically use Method 1 (Aggregate), see the Contributions Announcement thread for details about the current problems with tax and PayPal (basically it is due to the way PayPal rounds up to 2 decimal places whilst calculating the tax for individual items - which for Method 2 must be specified individually per item).

 

As noted above it is now possible to strictly enforce the verification and validation of a PayPal payment prior informing the customer that the order has been completed, this may be particularly important for those who offer downloads to occur once the customer has successfully (or supposedly) completed the order process

 

However, at the time of developing this contribution, I allocated the Christmas period to do this work, and I must now start focusing on finding an income, my wife will soon be refusing to feed me <_< and so further development of this contribution is not as much of a priority right now, that is unless somebody would like to contribute a donation B).

Edited by gregbaboolal

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

Link to comment
Share on other sites

I am using the latest osCommerce version and have the PayPal Shopping Cart v1.5 module installed. I am not using SSL. When I make an order from my store I get sent to PayPal to pay for it. No problem. However, when I click the return button to get back to my store I get sent to http://checkout_success.php, which obviously is a problem. I should be sent to http://www.whatever.com/catalog/checkout_success.php. Can anyone tell me what I have set up wrong? It is interesting to me that when I make the same order as a cash/check payment without using PayPal I get sent to http://www.whatever.com/catalog/checkout_success.php as I expect.

 

This is driving me crazy!

 

- John

Link to comment
Share on other sites

Hi John,

 

There are two ways to solve this,

[1] Change 'SSL' to '' (or 'NONSSL') in tep_href_link() on lines 180 and 181 in /catalog/includes/modules/payment/paypal.php,

OR

[2] in catalog/includes/configure.php I presume ENABLE_SSL is set to false and that there is no URL set in the line above HTTPS_SERVER, set that to be the same as HTTP_SERVER also ensure that DIR_WS_HTTPS_CATALOG is set to the same as DIR_WS_HTTP_CATALOG.

 

Greg.

Edited by gregbaboolal

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

Link to comment
Share on other sites

But now looking at /catalog/includes/functions/html_output.php it seems that you should of been ok (may be provided that ENABLE_SSL is set to false). Anyway if neither works, let us know.

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

Link to comment
Share on other sites

This might now suggest that a 'Pending' status should also be allowed to be registered via the PayPal - osC IPN (i.e. the one PayPal sends independently to your site - which I suspect is always sent prior to PayPal showing the customer their last PayPal page - where the customer would click the contiue button to return to your site).

These instances can be easily accommodated but requires a little more scripting to potentially find and update the corresponding PayPal transaction.

Thus at present it is left up to you the store owner to manually determine and update an osC order from 'pending' to 'processing'.

I am now starting to suspect that this really should be implemented in order to give the store owner the full (minimum) functionality that a store would require.

Let me know what your typical requirements might be, i.e. to allow 'Pending' PayPal - osC IPNs and then when it receives an update that the transaction's payment_status is now 'Completed' (i.e payment has cleared!) it finds that particular txn and updates the status accordingly. This is a primary step. The next level would be to start adjusting the status of an osC order i.e. 'pending', 'processing' etc, but I think it would be better not to try and tackle issues like that until the primary step has been implemented (just means that the store owner manually updates the osC order status - for now, the customer doesn't nessecarily need to be explicity told that their PayPal payment is still 'pending PayPal payment' - they would implicitly already know - since they should know the nature of their own finances and subsequent transactions).

 

Anyway I will not be able to look further into this until late next week, at the very least, etc..... feedback in the meantime will reduce brain ache :P

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

Link to comment
Share on other sites

hi....greg, i haven't tried yours yet...but i was trying v.0981...certainly got some admin sessions.php problems.....and i was asking and no one seemed to know...so i am thinking if i try yours now......but before i try, i am so sorry for my lack of the paypal ipn knowledge, but is this contribution also has the "customers don't click the continue buttom, but the information still goes back to the admin"????

 

 

:P sorry for the long expression...and am sorry for my english......

 

thank you a lot!!

OS-commerce is great, but with other magical contributions, that is just so "COOL"!

Link to comment
Share on other sites

My question as well.

 

Will this contribution add the order into OSC even if the customer does not click the continue button after the paypal transaction is complete?

 

Without this, I'm dead in the water.

 

Once I get clarification on this, I'm going to go full guns on this contrib.

 

Khim~

Do not meddle in the affairs of Dragons, for you are crunchy and good with ketchup :-)

Link to comment
Share on other sites

Yes it will,

 

What happens is that you receive 2 independednt IPNs, either of which will update the database, i.e. generate the order and order notification email. You will then be able to view the ipn osC admin, it will then link to it's corresponding orders page and show you the PayPal IPN transaction info, eg. payment_status, name etc, along with what you would see on the original orders page., so that even if you click to view from the orders link it will automatically include the PayPal info.

 

The two independent IPNs could be classified as:

 

[1] PayPal - osC

This IPN is sent independently from PayPal to your site (ipn.php). It try to thoroughly verify the transaction, ie. is it the right currency and does the total amount as what in the shopping cart match with what mc_gross amount the customer payed via PayPal

 

[2] Customer - osC

The is the IPN received when the customer returns the PayPal site, here a present it will follow the default proceedure of osC, i.e the order will be processed. This, at present will be irrespective of whether this IPN could be verified by PayPal (at present this check only checks for authentication, rather than currency and mc_gross) since more scripting is required if you want to notify the customer that there might be a problem, the customer will be allowed to continue to checkout_success.php but you will also get a seperate email warning you that at the time their IPN could not be verfied (maybe a communications error or someone trying to hack/hijack the payment methodology).

 

From what I can tell, [1] occurs first prior to the customer being shown the last PayPal page where they would then click continue and return to your site, subsequently if the PayPal - osC IPN has already been received an processed, then the customer - osC IPN is considered to be a duplicate and ignored, they will then be redirected to checkout_success.php with paypal=authorized in the url.

 

Please see the previous posts prior to this one for further insight.

 

My post two above this one discuss what I think would give you the full functionality that you might require, have a look at the previous posts and it may start to become clear.

 

Please also note the comment made at the end of the lengthy post I made on the first page!

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

Link to comment
Share on other sites

The question a store owner should now be asking is ok, it works, it receives IPNS and updates the database and processes the Order etc, which at this current moment in time onlu occurs when the payment_status specified by PayPal as being 'Completed' i.e:

If referring to an initial purchase, this means the payment has been completed and the funds are successfully in your account balance. If referring to a reversal (i.e. txn_type= reversal ), then it means the reversal has been completed and funds have been removed from your account and returned to the customer

Now since this PayPal - osC IPN is seemedly recieved prior to the customer returning to the site, if the PayPal - osC IPN currently has a payment status that is not 'Completed' then it will not process that transaction, however if the Customer does return to the site it will currently process the transaction regardless of the payment status, even though it may be 'Pending', 'Denied' etc.

 

Thus the store should now be saying ok hold I want this to happen, what are your minimum requirements?

 

I know this might take some consideration, but this isn't a cosmetic contribution, it something that will automate your commercial practice. I have developed the base code which can now be easily, extended upon to be as stringent as your require and to automate as much as possible. Sorry bit tired now, but please do have a look through the initial Contribution Announcement thread, and this support thread so as to get a better idea. A Link to that CA thread is in the first post of this support forum section.

 

Greg.

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

Link to comment
Share on other sites

payment_status

Completed

If referring to an initial purchase, this means the payment has been completed and the funds are successfully in your account balance. If referring to a reversal (i.e. txn_type= reversal ), then it means the reversal has been completed and funds have been removed from your account and returned to the customer

Pending

The payment is pending; see the  pending_reason  variable below for more information. Note: You will receive another Instant Payment Notification when the payment becomes  Completed,  Failed,  or  Denied

Failed

The payment has failed. This will only happen if the payment was made from your customer's bank account

Denied

You, the merchant, denied the payment. This will only happen if the payment was previously pending due to one of the  pending reasons  below

Refunded

You, the merchant, refunded the payment.

Cancelled

This means a reversal has been canceled (e.g. you, the merchant, won a dispute with the customer and the funds for the transaction that was reversed have been returned to you)

pending_reason

echeck

The payment is pending because it was made by an eCheck, which has not yet cleared

multi-currency

You do not have a balance in the currency sent, and you do not have your Payment Receiving Preferences set to automatically convert and accept this payment. You must manually accept or deny this payment

intl

The payment is pending because you, the merchant, hold a non-U.S. account and do not have a withdrawal method. You must manually accept or deny this payment from your Account Overview

verify

The payment is pending because you, the merchant, are not yet Verified. You must verify your account before you can accept this payment

address

The payment is pending because your customer did not include a Confirmed shipping address and you, the merchant, have your Payment Receiving Preferences set such that you want to manually accept or deny each of these payments. To change your preference, go to the Preferences section of your Profile

upgrade

The payment is pending because it was made via credit card and you, the merchant, must upgrade your account to Business or Premier status in order to receive the funds

unilateral

The payment is pending because it was made to an email address that is not yet Registered or Confirmed

other

The payment is pending for a reason other than those listed above. For more information, contact customer service

Edited by gregbaboolal

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

Link to comment
Share on other sites

There are two ways to solve this,

[1] Change 'SSL' to '' (or 'NONSSL') in tep_href_link() on lines 180 and 181 in /catalog/includes/modules/payment/paypal.php,

OR

[2] in catalog/includes/configure.php I presume ENABLE_SSL is set to false and that there is no URL set in the line above HTTPS_SERVER, set that to be the same as HTTP_SERVER also ensure that DIR_WS_HTTPS_CATALOG is set to the same as DIR_WS_HTTP_CATALOG.

 

1) both lines are NONSSL in /catalog/includes/modules/payment/paypal.php

 

2) ENABLE_SSL is set to false in catalog/includes/configure.php

 

3) Both HTTPS_SERVER and HTTP_SERVER are set to my domain in catalog/includes/configure.php

 

4) ENABLE_SSL is set to false in /catalog/includes/functions/html_output.php

 

5) My host is cURL-enabled

 

...But I still get the same errors, along with a lot of emails. The error emails indicate:

 

An HTTP Error occured during authentication curl= socket=tcp://domain=www.paypal.com port=80

 

and

 

Connection Type

curl= socket=tcp:// domain=www.paypal.com port=80

 

When I click the return button in PayPal to get back to my store I still get sent to http://checkout_success.php/?osC...

 

Any new ideas to try?

Link to comment
Share on other sites

Greg

 

Thanks for the prompt reply - I've set the email status back to 1 now as I'm happy the IPN's are being received and processed. Another problem I do have is that I make use of the gift voucher and discount voucher contribution and when someone pays via paypal the voucher is no longer added to the queue to be released so I have to email them one out instead (which I don't like for the fact the customer might get confused!).

 

I haven't yet checked to see whether I have erroneously copied over some of the gift voucher code, however when I installed your contribution I installed each file one at a time and didn't overwrite any existing files but went thru them line by line to see what you'd changed or added and made those changes to my existing files.

 

I'll see if I can get some time this weekend to look into this problem and work out where the difference between a paypal transaction and a cheque one is occuring and see why the GV code doesn't run.

 

cheers

Bill

Link to comment
Share on other sites

Hi John,

 

Others have had this problem too;

Replace the existing authenticate($domain) function in /catalog/includes/classes/paypal/ipn.php with the following code:

  function get_paypal_response() {
   $paypal_response = file('http://www.paypal.com/cgi-bin/webscr?'.$this->_response_string);
   return $paypal_response[0];
 }

 function authenticate($domain) {
   $paypal_response = $this->get_paypal_response();
   if (strstr($paypal_response,'VERIFIED')) {
     if($this->_debug >1 ) $this->send_email('VERIFIED',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return true;
   } else if (strstr($paypal_response,'INVALID')) {
     // log for manual investigation
     if($this->_debug > 1) $this->send_email('INVALID',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return false;
   } else {
     if($this->_debug) $this->send_email('unkown verification occurrence',"Connection Type\r\ncurl=$curl_flag socket=$socket domain=$domain port=$port\r\n#####################\r\n".$paypal_response."\r\n\r\n");
     return false;
   }
 }

Hopefully this will get you on track.

 

Ok, dunno whats happening with that link back of yours, one way to debug it would be to manually write that URL in those tep fucntions mentioned earlier. I know it's not clean, but at least it may work! view the source of the page and check that it is ok before clicking 'your' checkout confirmation that would take you to PayPal, might save some time before discovering that it still isn't fixed, let me know, but I might be tied up for rest of the day, will see later.

 

Greg.

Edited by gregbaboolal

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

Link to comment
Share on other sites

Greg

 

Please disregard the problem I had with the credit class/gift voucher contribution - I had not realised that there were 3 lines of code relating to it in the checkout_process.php file and I had not copied them into your version.

 

I am now happy to report that

1. i only get the one email confirmation

2. the order status changes to "paypal confirmed" once the IPN has verified

3. the emails now mention paypal as the payment method

4. the gift voucher purchases work seamlessly

 

So that's me fully sorted as far as I can tell. Excellent work!

 

I can certainly say to anyone reading this who's got Paypal IPN V0.981 installed - switch to this one instead, everything is superbly coded.

Link to comment
Share on other sites

Hi Bill,

 

Ok what i did was to copy the original checkout_process.php file into the /catalog/clasess/paypal/cart.php now if your credit voucher contrib altered that file (checkout_process.php) then that stuff will not be in cart.php as it stands. I only made 1 amendment to /catalog/checkout_process.php which was to insert the paypal_ipn_id into the sql array (do a search for paypal in that file). If your having difficulties putting the credit contrib stuff into cart.php let me know but I can't make any promises there, I'm getting behind on something else required for Monday as it is, + it may even require me having to try an install the contrib myself.

 

Greg.

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

Link to comment
Share on other sites

Hi Bill,

Glad to hear your happy, However you mentioned that your orders are being changed to 'paypal confirmed', my code doesn't do this which suggests that there a bits of PayPalIPN_v0.981 left in your system. Might be ok for now but I would make a point of identifying it, so that if my contrib gets updated (as such), it doesn't cause too much of a mess, if you see what i mean.

 

Greg.

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

Link to comment
Share on other sites

i had paypal ipn .0981 installed, and im fed up with it so im installing this. I have a lot of other contribs installed too, so i dont think overwriting will work, but there arent instruction about what changes were made in the code? help? thanks

Link to comment
Share on other sites

Hi Bill,

Glad to hear your happy, However you mentioned that your orders are being changed to 'paypal confirmed', my code doesn't do this which suggests that there a bits of PayPalIPN_v0.981 left in your system. Might be ok for now but I would make a point of identifying it, so that if my contrib gets updated (as such), it doesn't cause too much of a mess, if you see what i mean.

 

Greg.

Greg you're quite right I do have the remains of v0.981 installed - I am a little loathe to go on a mass deletion rampage so I'm going to leave everything as is for now and remove it piece by piece.

 

I know exactly the bit of code that's causing that change of status, thing is I quite like the fact it happens, so I'll leave it for now but if you do make a change I know which bit to strip out. I don't actually think it will be problematic leaving it in *fingers crossed*

 

What would be nice (maybe pointless, make of it what you will?) is that the customer is emailed the normal order confirmation, and when the IPN comes through they are sent a second email from the store to say "your paypal payment for order xx has been acknowledged as received".

 

Interestingly I haven't copied the credit class lines into cart.php yet - I wonder if it has only worked because I pressed the "continue" button in Paypal which triggers checkout_process to run. I shall copy the appropriate lines into cart.php as I presume this will do the necessary deeds even if that continue button is not pressed?

 

Cheers

Bill

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...