Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

totalnumpty

Pioneers
  • Posts

    239
  • Joined

  • Last visited

  • Days Won

    1

totalnumpty last won the day on November 1 2010

totalnumpty had the most liked content!

Profile Information

totalnumpty's Achievements

  1. But, quite honestly .... a commercial themes developer would naturally say that .... hmmm? "Vested interest" springs to mind.
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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))
  12. 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.
  13. 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"
  14. 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
  15. http://www.oscommerce.com/forums/topic/337797-shipping-insurance-2-0-need-help/page__view__findpost__p__1407391__hl__shipping%20insurance__fromsearch__1
×
×
  • Create New...