[checkoutpaypal] - modified to pay with any currency
|
anonimlt
Joined: 2010-02-11
Posts: 26 |
Posted: Sat, 2010-02-27 20:46
|
|||
|
Paypal accepts a limited number of currencies. If you would like to have prices in your local currency which is not accepted by Paypal, you may need this modified module. You will need to enter an exchange rate between your local currency and the paypal currency you have chosen, such as EUR or USD. It is possible to update currency rates automatically every day from xe.com, oanda.com or your country's bank. I haven't yet implemented this feature, because our currency is pegged to euro (fixed exchange rate).
|
||||
Posts: 26
Update:
Theres was a bug If your decimal separator (comma) differs from Paypal (dot), you cannot use this module. I hope I fixed it.
Posts: 4342
Can you list the changes for me?
Posts: 26
Added 2 fields to the DB, currency rate and local currency code. Local currency code is reserved for automatic currency updates and not used at the moment. Before sending payment to Paypal the amount is converted to the Paypal currency using the exchange rate from the setting. The number is formatted using number_format to have a dot as a decimal separator. In the IPN code there are some currency exchange calculation allowing for 2 cents of rounding errors (it may be that one cent is enough)
I have attached an entire folder. As an added bonus there are lithuanian language .po and .mo files for the buyer (not for admins, sorry, I'm lazy).
Run winmerge or other diff tool to see all the differences.
Posts: 4342
Interesting.
I'm not going to accept the changes as a new version of checkoutpaypal for a few reasons:
1. This is the wrong place to do this kind of thing. Doing it in the checkoutpaypal means that it won't work for other payment methods like Google Checkout. It would be architecturally correct to write a new module that uses the events hooks in checkout to adjust the transaction amount in the database.
2. It has a serious failure mode: if the exchange rate changes while a transaction is being paid for (which can take up to 10 days for eCheque payments) the payment will be rejected because the IPN doesn't match the right amount any more. The way around this is to store a per-transaction exchange rate. That works best in a new checkouttransactioncurrency table, which can be part of the new module that I mentioned in 1.
3. If I list costs in Zlottys (say), then convert to say USD for payment, and then pay on paypal using a credit card that's billed in Zlottys, I will pay a different amount because paypal's exchange rate is different. You can't have your customer pay a different amount than you said, that's extremely bad.
4. I don't like the idea of having to accept rounding errors in IPNs - they should match exactly.
However if these things are ok with you of course I'm pleased you've got it to work in a way that you like. I don't think it's a good idea to put them in a module for everyone.
I have been thinking about doing some multi-currency stuff for checkout, and some of the things I'm thinking for the future might be useful for you too. So watch this space...
This is a problem for the existing code when discounts are used, too. I posted a fix for this problem previously, in this forum. I will roll it in to a an update some time soon.
Posts: 26
I agree with you. The original idea was to make paypal payments work in case the seller's currency is pegged to some other currency.
regarding:
ERP systems have special accounts for currency roundings. There are many cases when rounding errors of one cent do occur while converting from one currency to another.
Example: 1000.01 LTL / 3.4528=289.62291473586654309545875810936~289.62 EUR
We get an IPN from Paypal in EUR, 289.62*3.4528=999.999936~1000.00 LTL
rounding error is one cent.
Posts: 4342
I know there can be rounding errors in currency transactions, the question is, where do you deal with them. What you've done is put an on-the-fly currency conversion - with rounding errors - right in to the middle of your security checks, so you have to break your security model to get it to work.
Posts: 26
transaction amounts should be stored in local currency and foreign currency, together with currency codes (and maybe rates). This is how ERP systems work. Then you check amounts you received without converting currencies, that's the simplest case, which may be just enough. I haven't looked at checkouttransactioncurrency table nor I know details of the gallery internal architecture. I could not find currency as a 'property' of the transaction so I invented my own wheel. Anyway, I understand what you wanted to tell me.