Jump to content

totalnumpty

Members
  • Content count

    239
  • Joined

  • Last visited

  • Days Won

    1

totalnumpty last won the day on November 1 2010

totalnumpty had the most liked content!

1 Follower

Profile Information

  1. totalnumpty

    Free templates?

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

    Official PayPal IPN Support Thread

    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. Hi all I've searched but didn't find an existing contrib for this, I'm hoping someone knows of one, or that someone who is a far better coder than me can pick the idea up and run with it. Here's the situation - on one of my osCommerce stores I have a very wide range of payment options, from multiple options for bank deposit/transfer/TT etc through various online processors (AlertPay, MoneyBookers, NoChex, PayPal, ppPay, Google etc) to postal payments and wire transfers. Generally there is no issue and they all work as well as can be expected, but now and them I get a PITA customer - you know the type, they select an offline payment method and when you follow up a few days later, asking where the payment is, they decide they want to use an online payment service instead - so you send them an (e.g.) PayPal money Request, they don't pay it, you remind them, they ignore it, and eventually you just delete the order and move on. Then a few months later, they come back and repeat the entire self-same process. Maybe doing it several times over a year. You don't want to delete or block their account, because just maybe one day they'll actually complete the order, or they may have purchased and completed the transaction somewhere else with you (like eBay or Amazon) and on your osCommerce site, they class as a returning customer. So here's what I want to do - On this site, I've got the Admin Notes contrib installed, so I can at least record that they've done the runaround described above, but I'd like to take it a bit further. Rather than block them completely, and obviously blocking the payment method for their tax zone is not a solution, I'd like to be able to prevent display of non-immediate payment methods for selective customers - ideally by way of some sort of "allowed / not allowed" checkbox list in the customers profile in admin. This would allow the maximum flexibility of making the restrictions apply only to specifically selected customers. I've no idea how to begin coding this, and very little about where such mods should be placed within osC, so I'm hoping someone can work with me and do the grunt coding, then use my site (and me) as a test bed and test installer. Anyone interested? Gaz
  4. totalnumpty

    Official PayPal IPN Support Thread

    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
  5. totalnumpty

    Official PayPal IPN Support Thread

    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
  6. totalnumpty

    Oscommerce Auction Lister Pro

    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.
  7. totalnumpty

    Official PayPal IPN Support Thread

    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
  8. totalnumpty

    Seperate Pricing Per Customer v3.5

    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.
  9. totalnumpty

    Official PayPal IPN Support Thread

    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.
  10. totalnumpty

    Official PayPal IPN Support Thread

    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.
  11. totalnumpty

    ot_loyalty_discount and paypal

    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.
  12. totalnumpty

    AlexStudio - are you around?

    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))
  13. totalnumpty

    Need help to install Paypal IPN

    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.
  14. totalnumpty

    PayPal Standard not updating in Admin

    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"
  15. Hi everyone I'm starting to pull my hair out on this - it started in late September just after all the eBay sites went to no shipping insurance. When a customer completes their order after choosing the shipping insurance (contrib = http://addons.oscommerce.com/info/1069) PayPal are either ignoring or stripping the insurance parameters passed through the API. The result is a payment received that is net of the insurance charge, but the customer's invoice shows both that insurance was chosen, and the correct rate for it. I've tried the patch in the contrib's read me, but that hasn't helped. I also tried the patch in another forum thread based off a different service's patch, and that didn't fix it either. I ran this contrib with the API module from nmid-2007 until September this year and it worked perfectly, like I say - it stopped working on my osC site right after eBay banned shipping insurance on theirs (eBay owns PayPal - for those that didn't know already ;) ). No code or contrib changes had been made on the site since around Easter. I'm convinced the issue has come from within PayPal, but so far, can't find anyone else reporting (or noticing) it happening on their sites. Has anyone else seen this happening? If so, has anyone cured it? Gaz
×