I would like some advice for localising using an _xclick and IPN rig.

A preference has been suggested to me for a system that can show different price points for each user's country consisting of some amounts combined with one or two currencies suited to that nationality.

For example, a European user may have the option of using Euros. These points would effectively determine what goes in the 'currency_code' and 'amount' POST fields based on a criteria such as Geoip, registered country, browser header fields, and so on.

However as far as I can ascertain there is no safe or effective way to do this. Anything we use to determine the user's nationality such as GeoIP could be circumvented to use the price point of a lower income country. If we didn't compensate for low income nations, exchange rates alone could pose a problem.

If we tightened restrictions we could end up showing the wrong options and making the user unable to pay without necessity. If we could consult Paypal about the user's currency before hand, this would incur unacceptable overhead and reorder the payment process in a way that is inconvenient.

As far as I can ascertain the best that can be done is to either let Paypal report an error if the user currency is incorrect based on Paypal settings (I don't have access to a Paypal merchant account so this is a black box to me) allowing the user to go back and select an alternative or to keep the system we have but use NVP and cached currency conversions to show the user the approximate price in their currency.

Can anyone use their experience to confirm/deny my analysis? Are there any alternatives I am missing? Any real world or open source examples?

In respect to the black box: I would be grateful for a pointer to any well written documentation explaining how Paypal handles varying combinations of currency_code (the form), the buyer's currency and the currency settings on the merchant account.