totalnumpty

But, quite honestly .... a commercial themes developer would naturally say that .... hmmm? "Vested interest" springs to mind.

Have you by any chance got more than one PayPal module active and installed? Just a wild thought that popped into my head. Also, don't know if this is possible or not, but have you got hard-coded embedded calls to an inactive PayPal module as well as to your active IPN? On-screen duplication I would expect to be due to duplicate code, but not normally to cause duplicate entries in the database - the "unique key" per table should prevent that. If you could check your database tables using phpMyAdmin and grab the row numbers and unique key column entries, it might help reveal if the problem is with the database, the write-to-database code, or with duplicate transaction (PayPal) code inside your site. If you see what I mean? If the problem is there and you can't fix it yourself, you'll probably need to put out a call for paid support from a competent PHP/SQL developer. Busy deep in the throes of site building - don't count on me being around here much before the end of next week. Gaz

Julian Hi The more I think about this, the more it feels it has to be due to the one page checkout - I've not implemented that on any of my sites yet, but can you check through the install instructions carefully looking for any code that tells you to delete / comment out hooks to the original checkout flow. Make sure you followed those accurately. Are you getting the same duplication from other payment processor modules? Or is it solely the PayPal one? Have a look at the module's contribution page in the repository, I seem to remember that the version you're using had some issue with being for German language sites only (or something like that). Unfortunately I don't have time to root around in this too deeply right now as I've got five complete site build, config, and style jobs to finish before month end and the job only arrived yesterday so nothing's been started on it yet. Good luck Gaz

Hi Julian I can't give you a definitive answer, but I can give you a few areas to look at for the cause of this. First though - did you spot that your VAT is not included in the total price? Here's my guess on that - PayPal has two IPN files in the IPN install. One is in the catalog/ext/..../paypal/ folder - that one is the IPN responder which receives the3 data from PayPal about a transaction and updates the order status in admin. For the order total problem, you can ignore that one, and for the duplication issue, it's very unlikely to be causing it, but you never know, as you say the order number is also duplicated. The other paypal_ipn file is in catalog/includes/modules/payments/paypal/ this is the one most likely to be the source of the order total problem and there's been loads of discussion posting detailed problems and the fixes, regarding that file. Normally, using the aggregate tax method clears it - don't worry too much about VAT accounting issues on the payment processor - you account for VAT from the invoice and in your accounting system, not at PayPal. This problem has been a long-running "open sore" with the open source PayPal modules. That second paypal_ipn is possibly, though unlikely, the cause of the order detail duplication - generally though, I'd say that if it was the source, then your invoices would be double the total price too, and you'd be spotting that pretty fast. My guess would be that the one-page checkout is echoing with the original checkout flow somewhere - probably in the order confirmation area. In the normal checkout flow, the last page of the process is where the order is written to the database and assigned the order/invoice number, then the whole is passed to the customer chosen payment module. Logic says that it's most likely at this point that the database is being written to twice, You've said the order is duplicated - but did you check if the order.invoice number is identical? (On the admin home page, hover your mouse over each order and look at the status bar at the bottom of the screen - it'll show the order/invoice number in the URL for the order). If the order number is identical for both, then you have a two step problem - osC is "printing" the order twice to screen as well as to the emails - that should be the easier to kill problem. Look for code duplication, or if the default checkout process is still active and working in parallel to the one-page checkout, instead of being replaced by one-page. If it's identical and in the database as two separate orders with the same number (which should be impossible given the auto-numbering osC uses with SQL) then you've got bigger issues - do you know how to use phpMyAdmin to inspect the database content and structure directly? You'll likely need to do that anyway - to verify if the problem is in the order recording, or in the osC use of the data after it's recorded. Sorry I can't drill straight to the problem, but hope the above helps you find it. Gaz

All eBay sites now require that all sellers seen as business sellers offer a return policy. Private sellers must make a return policy statement, even if that statement is "no returns". Since last Autumn (22 Sept 2009) eBay banned the shipping insurance options on all sites - it broke the osCommerce3 PayPal IPN modules using the Shipping Insurance contribs too. I have been searching for proof, and found it today on the PayPal Developer site, plus have finally (also today) been able to construct a fix to re-embed the shipping insurance charges back into the IPN data passed to PayPal, and get payment for them - it has taken me nearly six months to do this.

Strange - I thought the confirm order button was on catalogue/checkout_confirmation.php - not at PayPal I say that because it sounds like the checkout_confirmation order button is being activated twice or the checkout_confirmation.php page is being loaded twice (osC commits the order to the database when that page is loaded - including at a page refresh or if the back button is used to escape paypal). That's the most common cause of multiple records and order numbers for the same order. Example - if your site "home currency" is not the same as the transaction currency, nor the "home currency" for your PayPal account, then rounding errors occur during the currency conversions, and even if only a few pennies, some customers will use the back button to check that the PayPal total is truly not the same as the one shown by checkout_confirmation - that will cause two orders to be logged on their account, in the database, and on the admin/Customers/orders page. Other than that, I'd recommend you increase the level of server error logging to try and capture more information to point you to the culprit. Sorry I can't be more helpful. Gaz

If you're having to insert a multi-query in multiple places, why not just create a function for it, and then call that function where it's needed? You could then set all the parameters under the one function rule, and call the required parameters where they are needed.

OK, fair call - my bad, I was using generally understood shorthand pathing ... try this - /includes/modules/payment/paypal_ipn.php Just for the record in RC2a ... catalog/ext/modules/payment/paypal/standard_ipn.php hooks up with catalog/includes/modules/payment/paypal_standard.php and catalog/includes/languages/english/modules/payment/paypal_standard.php Therefore as I originally answered - No your premise of the single file in /ext/.... is still incorrect, and my original answer SHOULD have given you enough information to track down the other two files of the trio. The overall process I described remains the same for the standard_ipn in RC2a, it's just handled slightly differently by the code. Lastly, there perfectly well could be an /includes/modules/paypal_ipn.php in RC2a on a NON STANDARD install, which is actually the norm for osC sites - i.e. NON-standard (nobody uses it straight from the box and runs with it that way as a production site - that's just begging for hackers to visit your install). You could do - if you only have one website, will only ever have one website, and that one website will only ever be the sole source of payments into your PayPal account (i.e. no instant payment buttons, no auction sites, no WordPress eShops etc etc etc) - otherwise, read the help files and the instructions - within osC, and at PayPal - enter your /ext/... path in there and EVERY IPN or PayPal Express callback confirmation from your PayPal account will be sent to your website, many will be irresolvable (because they did not originate from the IPN on your site) and could cause server resource abuse due to SQL query loops and timeouts, and your hosting account could get suspended (I've heard several stories of it happening). If you ask for advice, listen to experience, and read between the lines if it's not an exact fit with your situation. Adapt what you're told to what you're experiencing ... and I do hope that's not "teaching granny to suck eggs"? Alternatively - follow the osC forum credo - and post your full site and server spec with version numbers, plus screen shots of errors etc, then people who help you are not firing blindly and generically when they offer that help.

Ken - your confusion is understandable, but your assumption is wrong. How it works is like this - - Once the customer has entered checkout and chosen shipping, and shipping options (gift wrap, insurance etc), the next step is the payment method - checkout_payments.php checks the customer address against the tax zones (geographic areas) for each payment method you have installed - if the customer is in the allowed geo-zone for PayPal, it offers payPal as a payment method - if the customer chooses PayPal, and goes to order confirmation, then checkout_confirmation.php assembles all the customer and order details and basically asks the customer if it is all correct, or if they want to edit anything. If they confirm it, then all that data is passed to /includes/modules/paypal_ipn.php - /includes/modules/paypal_ipn.php then passes that data to PayPal and redirects the customer to the PayPal website to sign in and choose funding source etc. This part of the IPN also passes to PayPal the data return path for confirming payment has been transferred to the merchant's PayPal account. - once the customer has done what's needed, and PayPal have moved the money to the Merchant's PayPal account, then the PayPal IPN server squirts a data stream back to your site - but the returned data goes to /ext/.../paypal_ipn.php NOT to /includes/modules/paypal_ipn.php - /ext/.../paypal_ipn.php then records the payment details into the database and updates the order status and transaction record, I think it also confirms back to PayPal that the payment data was received from them, and failing to do so is one common cause of payment failures. So the IPN has two parts - - the first paypal_ipn.php which is the payment methods module, and sends the customer and order details to PayPal, this is in /includes/modules/ - the second paypal_ipn.php which is the response receiver and order updater, this one is in the /ext.../ folder There is a third file in /includes/languages/{language-name}/modules/payments/paypal_ipn.php which controls the displayed language strings for the checkout pages and the admin payment modules page. So .... nope, the /ext/.../paypal_ipn.php is not all that osC needs - it needs all three files for any individual payment processor's IPN in order for that payment processor's IPN to function - regardless of which payment processor you're using (e.g. MoneyBookers, NoChex, AlertPay, ppPay etc.n Google Checkout is a little different, as is Amazon Payments, but the idea is similar). Each set of files will be named after the payment processor they handle - e.g. MoneyBookers.php and so on. Hope that helps? Gaz If any of the above is wrong, can someone post the correct process or logic - I think there's a few people get stuck with how the IPN's work.

Ditto How did you fix it? I have a feeling your fix may also apply to other modules having similar issues - e.g. the gift wrap module and the shipping insurance module. Therefore, please, even if your fix was to remove the discount module, please illuminate the rest of us.

Alex Hi It worked fine for two years but when eBay banned shipping insurance this September, all PayPal transactions from my osCommerce website using PayPal IPN also stopped collecting the insurance - even though the insurance is shown in order total and on the invoice after the payment has been made - at PayPal the payment is without the insurance. This is starting to lose me real money as the customer expects me to ship with insurance and not try to recollect it with a PayPal money request. Any help or pointers would be gratefully received Gaz (osC 2.2 RC1 + PayPal IPN 2.x (Oct 2007))

In your payment modules in admin, is it showing something names "PayPal incl Credit & Debit Cards" or similar, or something like PayPal IPN? Remember you have to activate the module, not just upload it.

That's the right module but roll back a bit on the versions to the last English version (I think it's 2.7.something) - use the expand all link at the top of the contrib comments and look for the last entry in English, then scroll down for the last entry stating it's "full package"

C'mon everyone - I can't believe I'm the only person having this - the shipping insurance was working fine right up until eBay removed insurance from their sites in late Sept 2009, after that, every transaction where the customer in my osC store selects insurance - the transaction is stuffed and no insurance collected by PayPal. Mind you, at least they've stopped sending invalid process emails on it, and it's sort of working correctly in the osC backend again (just no insurance collected in the PayPal payment). Gaz

http://www.oscommerce.com/forums/topic/337797-shipping-insurance-2-0-need-help/page__view__findpost__p__1407391__hl__shipping%20insurance__fromsearch__1

Those emails are triggered when someone tries to access the PayPal IPN file directly in the ext.... folder - looks like a test of some sort coming from someone who knows you have PayPal on your site (or could be a novice hacker trying to get at your IP login details). You can trigger one of them emails yourself by following the test instructions in the module's readme file. Gaz

I've checked the dates and times of several emails I've had which begin with - eMail Title = PayPal IPN Invalid Process $_POST: mc_gross=68.48 invoice=80 protection_eligibility=Eligible address_status=confirmed item_number1=(obfuscated) payer_id=(encoded) tax=0.00 address_street=(obfuscated) payment_date=03:54:25 Oct 28, 2009 PDT payment_status=Completed The bits above in brackets are changed by me to post here Basically the email is the entire transaction data, claiming an invalid process. On PayPal the payment proceeded normally. In the osC Admin transaction record it shows as payment failed. When I dig a little deeper - the optional Shipping Insurance module's value is not being passed to PayPal (or not accepted by them) and the monetary value of the insurance is missing from the amount received into PayPal, but still showing in the osC transaction record as chosen and paid by the customer. It also displays and prints on the invoice as such. The cynic in me says that since eBay banned option or compulsory insurance outside of the consolidated shipping charge (or total product price with "free" shipping) PayPal have now removed the option for non-eBay sites to process insurance through them. This issue is ONLY arising on transactions where the customer has elected for shipping insurance - if the customer decides not to request shipping insurance, the transaction processes normally. This is completely screwing our wholesale export business where everything is either C.I.F. (Carriage, Insurance and Forwarding) or F.O.B. (Frieght on Board) shipping terms. It's also royally beggaring our "bulk retail" business to small resellers where again all shipments are CIF or FOB at customer's choice. We're at the point of removing PayPal from those services because of this, and moving our customers to bank transfer only - most of them have indicated they would understand and accept such a move. Has anyone else had issues with PayPal and the postal/shipping insurance field? It's completely non-present in the full values list emails we're getting on these invalid IPN emails Gaz

So when is the rest of the world going to get it? (just as importantly, when will the rest of the world be allowed to sell on Amazon Marketplace etc?

I think we both agree that osCommerce needs to have some dedicated time applied to modularisation. My original intent in replying was not to try elevating one software over another, but to illustrate examples from how other packages are doing modular expansion. As I said, I like osCommerce - I like its flexibility and expandability, and that generally speaking, the core files system and conventions are very logical once you've had a little time to explore them. It is the routine upgrades that are a real bind - whether it is actually the effort required, or the way the scope of the changes is presented, I'm not sure, but I've not upgraded any of my sites from RC1 to RC2 because the amount of work implied is simply too much. Then there is also the effect of core upgrades in relation to "monster mods" - CCGV / CCGV(Trad) especially springs to mind. CCGV v5.20 was apparently the last stable version and that worked with osC 2.2 MS2. Since that version, the forums are full of howls of agony from users unable to complete installation into an RC1/2 install. The developers for CCGV(Trad) have emphatically refused to attempt a port of their version for any RC osC version and have repeatedly stated they will wait for the final osC release - that leaves everyone who downloaded osC from osC.com between mid 2007 to present and into the future, unable to use either CCGV version. CCGV is not the only "monster mod" with this issue, SPPC appears to have revolving issues according to the forums. When I read the latest queries from the threads related to SPPC and other price tiering modules, I get the impression that osC's architecture is designed to stop such modules from operating successfully - however, I also blame the contrib authors in part - each time a fix or improvement is uploaded, they RARELY state which osC version it applies to and I suspect too many support seekers are simply downloading a package that looks as if it's for their osC version, but isn't, because the contrib uploaders did not include enough versioning information. osC core teams and the osC website are to some extent also guilty in this - there is a general dearth of info about the core code differences between the older MS2 and current RC series - what I'm referring to is for the "little changes" such as the one that killed off so many mods in the MS2.2 to RC1 switch in the overall checkout/payment/shipping core code files. I lost count of how many wasted hours were spent trying to add a mod, discovering the install location had code changes, and then having to rip out progress so far and look for a different contrib to do the same job because the one I wanted was no longer compatible with an RC osC. This then of course comes back to the old argument of should RC versions of osC be the prime distribution file set? Like many others, I believe that in July 2007, Harald & Co made a major blunder by removing MS2.2 as the primary download and replacing it with RC1. They should have offered the two alongside each other, offering MS2.2 as the stable version, and RC1 then RC2 as the latest public availability of the development version. Had they done that, my sites would have been on MS2.2 and CCGV and SPPC would be installed and running, instead of missing, and I would not be having to run separate sites for wholesale & distribution customers instead of having them integrated under one site with the retail interface. Unfortunately, my sites were originally installed (basic install and setup) by someone else, who simply grabbed the offered download version from osC.com and ran the install without checking version number. The version number also did not become significant until a couple of months of site development and product populating work had been done, then it was too late to revert. I suspect many webmasters new to osC have found themselves in that position. The summary point is that there needs to be a better system for completing core code upgrades, or at the very least a better way of presenting the upgrade instructions, such that they don't inhibit users from upgrading. I also believe that (as with RC1 and RC2 for example) when core devs decide a major function like checkout needs a major operating code rework, that the core devs put out a consultation call to the contrib devs whose offerings rely heavily on the then current operation system for the section to be upgraded - dare I say IPN & API call back functions from payment processors + CCGV + the completely reworked checkout_process.php between MS2.2 and RC1 and RC2? Gaz

Errr - not quite A blog has posts, and comments, and threaded replies, and threaded discussions, and pingbacks, and trackbacks, and many of the functions of a wordprocessor and DTP package, including all of the html available to osCommerce product descriptions, and a whole lot more besides. Products have prices ... yup, as demonstrated by several full featured shopping carts that are simply copy-and-activate plug-ins to WordPress. osC itself is also just a plug-in for Joomla! within the CMS structure of that package. In addition to categories, blogs also have tags and authors and editors and contributors and a host of other post/product taxonomic data that does not exist in carts - this balances out the cart's tax and products-into-cart functions. Additionally, whilst osC reviews can have star ratings, so can blog posts (and comments, and even the images - all rated independently of each other within a single post or page entry) it just needs the plug-in to be uploaded and activated - there's around 20 or so different ones, each with a slightly different focus or style, to choose from. The cart's checkout system is undoubtedly the biggest coding difference between a blog and a cart, however, consider the massively multi-user "product creation" functions native within most blogging softwares - from basic commenter, to contributor, to author, to editor to admin (using WordPress heirarchy) as opposed to the single admin native to osCommerce. Blogs win therefore on organisation scalability. On this topic, WP comes in two flavours - single blog version, and WP-MU which is massively multi-blog management within a single install. osC has the Multiple Stores from single install contribution (it's a monster to install and highly unstable when adding further contribs in my experience) therefore why not target osC 3.x to release in two variants the same as WP - single store and multi-store - until they do, WP is way ahead of osC or Zen or any other cart system on that one. External shippers and payment processors - see the comments above about the cart plugins for WP and other blogs = identical functionality but in a drag and play plug-in. Equal ranking therefore, though the plug-in system of WP actually keeps it ahead of osC on this one, due to the ease of 1-click upgrading when (for instance Google Checkout) a payment processor makes radical changes to their API or terms of service and the plug-in author upgrades the plug-in's code, but not every blog script is as advanced as WP. Blog plug-in carts are multi-currency too, and via a plug-in, all monetary value mentions in any WP post or comment or page can also be made fully and automatically multi-currency - polling the reader's IP address to get their country and auto-converting to the local currency of that IP address with exchange rates pulled from the likes of XE.com and other servers via a cached currency chart (timing of which is usually schedulable via WP-cron or server-cron, including multiple times per day). Currently this is a drag and drop plug-in for WP, but not for osC, and even the contribs that are available, have to be merge-installed to get the same full functionality, even then they only work on catalog product's prices, not the prices quoted in text from the language files (e.g. a shipping insurance compensation narrative in /shipping.php). Blogs win emphatically on that one. For WordPress it's a drop and play plug-in called "eShop" - and it can be used for both digital and tangible goods, supports PayPal style processors as well as the online direct card processing services and merchant services. See? That's part of the problem - you're approaching it as a programmer, not as a retailer or wholesaler. Options are exactly that - options! They are either free, or cost extra. That's all a customer wants to know on the pricing front. Therefore code it as "this extra stuff costs this much to add it into the bundle" - anyone doing more than that is just making life to difficult for the buying customer and they'll click off to where it's easier to buy. Hmmm ... OK - to me "getPriceFormatted" should be stored in the customer table, and based on their country (comma or period between currency unit and cents? etc.) which will yield the correct currency symbol ($ etc) and whether it should be to the left or right of the actual value. All this should be pulled either from the countries database, or from a flat file that can be edited within the admin interface (sayyyy ... would that make it a .... module ... by any chance?). Horses for courses - I've never been able to get to grips with diffs - gimme a set of text install steps and the code to copy over. Of course, that easily deprecates in favour of a real drop-and-go modular plug-in system like WordPress's ;) Gaz

Sam - I disagree in two directions .... My suggestions / wish list for the contrib library is both simple to implement (but would be tedious to enforce) and logical. In fact it would make life simpler for everyone - core devs, contrib devs, and contrib users. The prime workload would be on splitting out existing contribs and separating the existing uploads to be osC version specific. If you think of "monster" contribs like SPPC or CCGV that have evolved over 6+ years and covered half a dozen or more osC versions, then that illustrates both the splitting task difficulty and emphasises the absolute necessity for doing it. As to the contribs themselves - I'm assuming you mean by "slow down" that you're referring to how the site actually performs, rather than the speed of development. In terms of the former (site speed) then seggregating contrib modules and using INCLUDE calls would have a minimal performance effect unless the contribs themselves were over-heavy in database calls or constructed as bloatware. If you mean the latter (speed of core & contrib development) then I assure you you are wrong, as the other softwares prove daily. In fact, the WordPress plug-in system actually speeds development because the devs focus on their own product and their XML install file simply inserts a call to their plug-in at the correct point of the core code. This encourages the careful development of custom functions within the plugin files (usually in a /pluginname/functions.php file) and greatly reduces both conflicts and the time needed to identify and debug them. Just browse any of the osC forums and you'll see that "contrib conflict" is a major and repetitive get-out-of-jail-free card played by many contrib devs. That occurs far, far less in WP and the other softwares. Burt I don't think it's being unfair. osC RC1 is 2 years old this month and is a nightmare to upgrade to RC2 or RC2a for non-programmers like myself with multiple sites out there. Both WordPress and SMF forums are one-click upgrades even between major version numbers - it took one click and 45 seconds of twiddling my thumbs to upgrade from SMF 1.1.8 to SMF 2.0 and that was a huge core code and database upgrade. It takes even less with WP upgrades since v2.7.0 I've looked and looked at the diff files for an RC1 to RC2 to RC2a upgrade, and even though I can hack and tweak with the best of them, I'm not even going to attempt those core changes on any of my sites - it took me long enough to get them all running smoothly, and one site in particular has well over 100 contribs hacked into it, plus countless tweaks from myself. If those 100+ contribs were all genuine modules, then it would be a few clicks and a few minutes - step 1 - click box to de-activate all plug-ins step 2 - click button to run core & database upgrade step 3 - tick boxes for plug-ins to reactivate, and click button to reactivate them step 4 - view site and confirm all's well, then write a blog post to tell everyone how easy it all was. That's the type of architecture that's leaving osC in the dust. Whole new web-based provide & host services have sprung up in the last 2 years based on providing exactly that for modified osC auto-installs (e.g. EKM PowerShops) Core dev needs desperately to catch up with the rest of the industry if osC hopes to maintain the user growth momentum of the last few years. As much as I like osC and enjoy tinkering with it (anything to avoid real work - right?) pretty soon someone will likely launch an alternative of the type I describe, also open source and free, and watch the user base dissolve then. I speak direct because I care. I LIKE osC, but it's time to get it out of short pants and make it less geeky, and give it the fancy duds so it can go disco-ing like the cool big kids. Gaz

I see a lot of the old-hand programmers ignoring one of the basic premises in the opening post I agree with Johnnyrocket that modular means modular - consider the use of so-called modules within the osC contrib environment and do a comparison with the plug-ins in the WordPress environment and you'll see what i mean. Adding a plug-in in WordPress is an "upload all and click activate" process, then configure plug-in unique settings via the admin side of the site using a user interface page. Same applies with theme changes generally (pre-personal customisation and sidebar widgets addition). It seems to me that here on osC, a contrib is not a contrib unless it requires extensive hacking of core code, non-auto-removal injection of database tables and rows, plus endless bug hunting and swapping out of deprecated commands. My vote goes to the following steps - In the contrib library - - split the contribs library by earliest known supported osC version for each contrib - when a contrib has a "major sub-version step to fit osC version XYZ" update, then that contrib version gets a new contrib library entry with lowest compatible version being the osC version it has just been updated to work with. - when a new osC version (Beta or RC or final) is released and the contrib does not work with it, then the contrib page is annotated in the header to state that version ABC is the highest working osC version for this contrib version, and that development for higher osC versions has been forked to a new contrib at (link). - if a developer wants to post a contrib (and as with one page checkout) state no free support is given, then the contrib library page must have a big red box warning of this condition, or a separate section in the contrib library for contribs demanding paid support. In the contribs themselves - - NUMBER ONE - as far as is possible, the target for any contrib should be that it is a drop-in module (copy files to folders and click go in admin) - study WordPress to see how they do it. - contrib authors should re-examine all code before publishing it, and in particular, - - language strings should have their own language file in includes/languages/languagename/modulename.php or be inserts to the includes/languages/languagename.php file - they should not have hardcoded language strings scattered throughout them. - - The same applies to any constant values and image names/locations hardcoded instead of added through the language files. - - User ID codes (e.g. payment service account or affiliate codes) should be insertable through the modules page in admin, not hardcoded in the module files with install instructions to edit them before install - the defaults in published code should always be NULL, not the contrib author's own affiliate codes etc. There's probably a hundred further issues I could drag up, but underlying them all, I think, is the fact osC architecture is not designed for the same degree of user modification as other packages (not just WP, think Joomla, SMF forums et al) and osC's architecture in this respect is really showing its legacy and age. If I had one wish, it would be that osC 3.0 was focussed solely on bringing the contrib and theme modification architecture to the same level as those other open source packages. Forget everything else, including (dare I say it?) security upgrades etc - just get the contribs and theme systems up to date with the rest of the industry. Gaz

Hi - just about to try a test build RC2a store with the latest version of this contrib, but after download I found it is a tar file Any chance someone could be kind enough to re-upload it as a plain old ZIP package? Please - pretty please?

Hi Jan You've posted that QPBPP v2 is for SPPC 4.2.2 which is for RC2a of osCommerce Does QPBPP v2 install/work identically with SPPC 4.2.0 for osCommerce RC1 ? I ask because my site is far too heavily modded from RC1 to easily upgrade to RC2a (it would also break several essential contribs if I upgraded). Thanks Gaz

That's being extremely unfair to both the osC and the mod developers, as well as to the PayPal tech teams Have you THOROUGHLY checked YOUR versioning at your install to ensure full compatibility? - osC version & IPN version? Not every sub-version of the IPN mod works with every osC sub-version - there was a big code change in the checkout process between 2.2MS2 and 2.2RC1, plus additional changes between 2.2RC1 & 2.2RC2. Some of the IPN versions are written to ONLY work with 2.2MS2, others to only work with RC1 or RC2 - this is due to how and when the order is saved to the database (i.e. before or after customer returns/does not return from PayPal) amongst other factors - it is why CCGV(Trad) and other monster contribs only work with MS2 and not the RCs. PHP, SQL versions - again there are differences that have caused hiccups I have an RC1 install that I first put onto a 4.20 server on a UK host and added in over 100 contribs. I then cloned it to a 5.x server in the US and redid the visuals etc, a month later I am still verifying all the site functions and contribs work - mostly they do, but I have found one or two that needed the odd tweak to bring them into the 5.x realm Contrib Clashes Have you checked if other installed contributions have caused a hiccup for the IPN - especially any that modify the checkout process (e.g. a not obvious one is the gift wrap contrib - it modifies the process, but thankfully causes no conflicts with the IPN). Install & settings for IPN A common problem is users simply ignoring some of the MUST-DO's in the instructions. These include things like the aggregate or per item setting, the clearing or setting of P&P table rates AT PAYPAL, setting the return call for the API at PayPal etc. PayPal is a pain in the butt to get working 100% and stable (though looking at Google checkout, PayPal is easy to set up compared to all the 1-account per selling location + SSL compulsory etc that Google insist on). However, I got it working first time on both of the sites mentioned above, and on another MS2 site. I'm NOT a programmer, I'm a copy & paste instruction follower - if I can do it, anyone can. A wise man once said, "It is a poor craftsman who blames his tools" - as I have found with osC, this is very true, and usually problems are not due to bugs and glitches (usually I said) but due to insufficient slow, methodical, rechecking of the install and set up. The clue is always, "How many people is this already working for, and why am I having a problem?". If it's working for nobody, then assume the code is the problem, if it's working for almost everyone, then assume it's what you have done (or not done). Gaz