Chris H

Thanks MrPhil, well spotted.

No reflection on burt's analysis, but satisfy yourself that you are looking at the right instance of 'amount' => $this->format_raw($order->info['total'] - $order->info['shipping_cost'] - $order->info['tax']), Comment the line out, to check that the transaction fails. Then try changing it to 'amount' => $order->info['total'] - $order->info['shipping_cost'] - $this->format_raw($order->info['tax']), Suppose that 'tax' is rounded down by format_raw. In the quoted line of code, it is preceded by a minus sign. So there may be a sense in which 'amount' is rounded up. This would cause a one-penny discrepancy. The two basic numbers in your screen-shot, 31.63 and 37.95, seem to be related as follows 31.63 * 1.2 = 37.956 That is, the 20% vat has been applied to the item values only. Not to the whole order value. We haven't been asked to discuss legalities, but are you sure that is the correct treatment? If you have been undercollecting vat then an occasional rounding error is the least of your problems. There is a further mystery in the line Total Vat @ 20% Included in the Above £7.23 This figure seems to have been derived as 43.35 / 6 = 7.225 but we must divide by 5, not by 6, to split off the 20% vat. Is this 'Total Vat' consistent with the Paypal page, in the case of a successful transaction? Sorry to be just negative. But if the code is fundamentally flawed then fine-tuning, to fix a rounding error, would be premature.

From the osC home page we can click through to Products > Online Demo > View > Source to view the source, and specifically to view line 6 which reads <base href="http://demo.oscommerce.com/" /> The domain-name, as here given, ends with a forward-slash character. So your <img src="/images/credit_cards.gif" can be changed to <img src="images/credit_cards.gif" like in joli's code. Or it might need to be <img src="catalog/images/credit_cards.gif" depending on your directory structure. Just don't start the pathname with a forward-slash.

According to a discussion in the German-language forum, you need to update from 2.3.3.3 to 2.3.3.4 http://forums.oscommerce.de/topic/81909-fehlermeldung-bei-paypalzahlung-nach-update-auf-2333/

Like Mort-lemur says, though there is always the customer who registers with an address that is near to you, with the intention fraudulently to secure a lower postal charge. There is no automatic check for this, you will just have to keep your eyes open. If however we think in terms of whole states, not of specific postcodes, then there is less vulnerability to this fraud. In the case of an Australian address, Paypal returns the values of SHIPTOSTATE SHIPTOCOUNTRYCODE and if function pre_confirmation_check function pre_confirmation_check() { global $HTTP_GET_VARS, $order, $ppe_token; if (!tep_session_is_registered('ppe_token')) { tep_redirect(tep_href_link('ext/modules/payment/paypal/express.php', '', 'SSL')); } if (!isset($HTTP_GET_VARS['do'])) { $response_array = $this->getExpressCheckoutDetails($ppe_token); if (($response_array['ACK'] == 'Success') || ($response_array['ACK'] == 'SuccessWithWarning')) { // load the selected shipping module include(DIR_WS_CLASSES . 'shipping.php'); $shipping_modules = new shipping($shipping); include(DIR_WS_CLASSES . 'order_total.php'); $order_total_modules = new order_total; $order_total_modules->process(); if ($response_array['AMT'] == $this->format_raw($order->info['total'])) { tep_redirect(tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL')); } else { tep_redirect(tep_href_link(FILENAME_CHECKOUT_CONFIRMATION, 'do=confirm', 'SSL')); } } } } is not happy with what it sees then our visitor does not get through to checkout_process. It is still common to offer free shipping on valuable orders, though the practice looks like a relic of the days of printed catalogues. It would have been too much to ask the householder to dip his pen into his inkwell, to start adding up weights. But we can nowadays charge prices which more accurately reflect our costs, and the competition may force us to do so. So maybe place more emphasis on weight-based shipping - more especially as some of the products are 'quite heavy'.

If we add 157.46 to 17.50 then we get 174.96 not 174.95. It looks like a rounding error inside the add-on.

Perhaps you have imposed a severe access restriction, such as password protection, whilst getting set up. Your website, and the Paypal server, need to be able to talk to each other. Failing which, PP error messages cannot get through.

My own solution, to a similar problem, was to create a column called 'zone' in the countries table. Some of the entries, in the column, are 'EU' and some are not. $query = ' SELECT zone FROM ' . TABLE_COUNTRIES . ' WHERE countries_id = ' . $order->delivery['country']['id'] ; $result = mysql_query($query); if ($result) { $row = mysql_fetch_row($result); } So your if (XXX){ is then if ($row[0] != 'EU'){ For the archive, I don't believe that this law has been ratified in all EU countries. Or even in most of them.

Can't be much help, other than to list the key/value pairs that are ordinarily sent to PP Express. Presumably Dynamo does the same. VERSION=60.0 METHOD=SetExpressCheckout PAYMENTACTION=Sale RETURNURL=http%3A%2F%2Fwww.xxxxxxxxxx.co.uk%2Fcatalog%2Fext%2Fmodules%2Fpayment%2Fpaypal%2Fexpress.php%3FosC_Action%3Dretrieve CANCELURL=http%3A%2F%2Fwww.xxxxxxxxxx.co.uk%2Fcatalog%2Fext%2Fmodules%2Fpayment%2Fpaypal%2Fexpress.php%3FosC_Action%3Dcancel USER=sales_api1.xxxxxxxxxx.co.uk PWD=ARNAX5YR3SFRGDYB SIGNATURE=AmiDcmdWJ6782BCw9VRzBNLUVRzQAkKCgBxPOld8XsatimkyBNSydOGq SOLUTIONTYPE=Sole CURRENCYCODE=GBP L_NAME0=T+shirt+with+Coca+Cola+logo L_AMT0=0.02 L_QTY0=1 L_TAXAMT0=0.00 ITEMAMT=0.02 TAXAMT=0 L_SHIPPINGOPTIONNAME0=Flat+Rate+%28Postage+and+Packing%29 L_SHIPINGPOPTIONLABEL0=Flat+Rate+%28Postage+and+Packing%29 L_SHIPPINGOPTIONAMOUNT0=0.01 L_SHIPPINGOPTIONISDEFAULT0=true INSURANCEOPTIONSOFFERED=false SHIPPINGAMT=0.01 AMT=0.03 MAXAMT=100.04 This records the purchase of one instance of one product. The values of SIGNATURE, and so forth, have been slightly altered. I seem to remember there was also something called L_NUMBER0, which I took out of the php. And no, I haven't mis-spelled L_SHIPINGPOPTIONLABEL0. The osC developers like it that way.

kymation's point is well made, that the API test results are generated by Paypal. It may be worth mentioning for the archive that RETURNURL and CANCELURL can be set on a per-transaction basis in function setExpressCheckout($parameters) which is itself in catalog/includes/modules/payment/paypal_express.php This over-rides PP account settings. A merchant might after all have several stores, and thus need several RETURN and CANCEL URL's.

Dunno. As a last resort, have two shops www.proudmary.me/winkel www.proudmary.me/shop They can address the same database. The google-searcher has chosen a phrase from a particular language. Having implicitly specified a language, he is happy to get through to a page that offers that language and no other. I am sceptical of the multi-language thing. A fresh install is likely to be easier than copying the winkel directory. And then re-naming the copy. And then fiddling about with the configure files. It has to be an 'upload install', so far as I can see. Fantastico would insist on making a new database. How much of the duplicated admin can be deleted, I do not know. Try it and see. A directory can be 'half-deleted', by vandalising its name. The code, that is looking for it, cannot then find it. Then it's a case of getting into includes/languages/english.php to change 'welcome guest' to 'welkom gast'. Leaving the filename unchanged of course. Like Bertil, I don't see that you need a 'catalog' directory. Directories like 'images' and 'includes' can be directly under 'winkel'.

For the sake of the future searcher in the forum archive, it seemed preferable to not start a new thread on an old topic. He is presented with dozens of threads, all on much the same theme, and having the usual gaps and overlaps in the information that they offer. But, with hindsight, I can see that it looks like I barged into the conversation and I apologise.

Looking to convert my site to osC, I wish to stay with Paypal Standard (with which I have years of experience) rather than change to Paypal Express. But I hunt in vain through the osC programs, looking for an 'include' or 'require' or 'define' statement which mentions paypal_standard.php. Neither is the filename the value of a key/value pair, such that it could be referenced by key. Which of the forum's helpful experts will explain to me how, exactly, 2.3.1 runs paypal_standard.php ?