It looks like this is not a new issue - we were only made aware of it as we now hardcode the donation link in fundraising emails. So where the link would previously have geolocated and not been a donor-facing issue, donors are now landing on the UK form as they are part of that list and received the UK mailing. But if you look in mailing events, in some of these cases donors have been on the UK list for a number of years (all have given in GBP once in the past, but not recently).

So the question is: Why did their country not import (or get overriden in Civi) when their newer donations made in the correct currency and country of residence came in? And why is it the GBP donation that is sticking, when many more have been made in another currency (including earliest and most recent)?

@KHancock99 found another one: Canadian donor on the USA send list here: cid=49222232 (only ever donated in CAD, with a Canada residential address too), although there is another Civi record with USD here: 59101896 (same email). The earliest donation was in CAD, but I guess they were travelling so donated in USD in 2022, and that has stuck, somehow.

Why would we choose one over the other? (I'll merge these down the line).

Looking at the first one of these[[ 57682669 | https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=57682669&selectedChild=report_101 ]] - her country has been set to GB since 2022 - & it has been that in the contribution tracking record - I need to check whether

1. we don't collect the country on the form because we assume the country in the url is right or
2. we collect it & ignore it....

OK - I found what is hitting donation queue consumer (donations_queue_consume-20241127-131401.log.civi1002.bz2.txt) and the donation message has

street_address - address in Denmark
city - city in Denmark
country - en_GB

I will check with @Cstone & @Wfan but it looks like we are putting country onto the form as a hidden field & using the url value

In payment-wiki yes, country is as hidden field, can only manually updated in URL, currency is also hidden, while when we are getting unsupported currency in url, currency will show the drop down to choose other to donate. But for donate wiki, country was geolocated and can chosen in the drop-down, currency is depends on country.

So it seems the donor will have seen a chance to change country like

But if they do not select it there we don't ask again / present it to them. It seems like @Pcoombe added that in August-ish

The decision to omit country (eg. on the payments form) is around form completion rates but there is the accuracy trade off

In T381437#10379096, @krobinson wrote:

It looks like this is not a new issue - we were only made aware of it as we now hardcode the donation link in fundraising emails. So where the link would previously have geolocated and not been a donor-facing issue, donors are now landing on the UK form as they are part of that list and received the UK mailing.

I didn't realize we had switched to hardcoded countries, did we do it to handle the geolocation currency issue? Like 1000 JPY to 1000 USD?

In T381437#10379096, @krobinson wrote:

So the question is: Why did their country not import (or get overriden in Civi) when their newer donations made in the correct currency and country of residence came in? And why is it the GBP donation that is sticking, when many more have been made in another currency (including earliest and most recent)?

Putting more data from the examples here:
cid=57682669
Their first donation was in GBP, country=GB, but rest of address in Denmark. (Somehow they got to the GB form in 2022)
They then kept donating in DKK. We aren't collecting address info on the Denmark form so their country was being sent through as DK, but nothing else -> address didn't get updated, country still GB

cid=14000414
Their first donation was in EUR, country=IE, no other address data
In 2019 their full address was submitted, but somehow they got the GB form so country=GB and currency= GBP
They kept donating in EUR but we aren't collecting address info on the Ireland form so their country was being sent through as IE but nothing else, and the address was not being updated

cid=37086081
This one is paypal so somehow GB got in there to begin with, and then US wasn't enough alone to update it

Options on how to handle this:

• Current civi code is not updating an address based just on a country change. I think we probably still want to keep it that way? But it will cause situations like this. Maybe if only country is there, overwrite that?
• Another way to deal with this is to add in more address fields on credit card forms that don't currently have them. That would need the donor to be geolocated to the country to get the right form in the first place but it would have helped the first two example donors

Hiya @Cstone, to answer your question:

I didn't realize we had switched to hardcoded countries, did we do it to handle the geolocation currency issue? Like 1000 JPY to 1000 USD?

the answer is yes, we've opted to hardcode the country=XX parameter in donate.wiki URLs in recent campaigns for the reason you mention.

The rest of this comment doesn’t pertain to this task exactly, but I’m adding it here for more context. Hardcoding the country is not a foolproof solution, as there are scenarios where it can have the opposite effect.

Example of where hardcoding country works against us:
Donor is on our US audience and receives a US email campaign (...&country=US) but their latest donation was in Mexican Peso e.g. 500MXN. Their donate.wiki URL on the email will then look like
https://donate.wikimedia.org/?country=US&hpc=500 which will render ask amounts of $500 USD and upwards.

@Eileenmcnaughton what is the status on adding more wmf_donor fields, could we make a last_donation_country and calculate that on civi's end based on the latest currency?

@Cstone if the last donation country is just based off the last donation currency then isn't the field just last_donation_currency by any other name? Or is the point that they can't transform USD to US when sending emails from Acoustic & putting the country in the url?

Yeah second part Eileen I was trying to think of a way to fix the issues with the bad data we already have where you could be on the US list, but last donated in MXN like in Panos's example

@Cstone - hmm - but maybe it makes more sense to pass the currency in the url since that is the information that is accurate? Because sometimes the donor country WILL be right & it seems like it could get confusing

p.s. here is another donor coming from AU with donation in AUD, but marked with country US https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=66781861&selectedChild=summary

Coming back to this issue, @ppenloglou @krobinson to summarize the above:
Emails have donation links that have the country hardcoded will automatically use that form. Some countries have more address data than others, so if a donor had been in the US (all the address data) then moved to Denmark (only country address data) and donated, the civi address does not get updated to Denmark and then Acoustic will not get updated to Denmark.

Would we want to overwrite a full US address to just the country? I guess its the amount of these that you are getting and how much you think this is from a permanent move vs someone travelling and donating.

I think we should go with more recent, especially now we have the country selector. We should assume the donor is choosing the correct country, even if that means overwriting a full address with just country. Unless we can make the old one 'old' and import the new one as well. So long as we are pulling and referring to the correct (new) one when we code the email, I don't see having both in Civi as being an issue.

@ppenloglou Is there a reason why you went to hardcoding country vs hardcoding currency and amount?

@Cstone On donate.wiki, the currency displayed is dictated by the currently selected country of the page. That is why we opt to hardcode the &country= URL parameter in our ask hyperlinks.

Examples:

• USD $ = https://donate.wikimedia.org/?country=US
• MXN $ = https://donate.wikimedia.org/?country=MX

Adding to that: there's no way to directly select a currency on donatewiki, only a country. Selecting currency would require a pretty substantial re-working of the current donatewiki setup.

ahh that makes sense @Pcoombe @ppenloglou thanks for explaining. Was thinking too much in the payments wiki world

Hey all, can I get a status check on this issue?

@AMJohnson just had to refund (for the second time) an inadvertent major donor who is based in Japan and has always donated in JPY but somehow was on the US list and received endowment emails, and gave without meaning to 5,000 USD instead of 5,000 JPY. We have now changed his country to Japan, which should fix this one going forward, but it would be good to understand how we are capturing the donor's country in these cases.

Do we pull email lists based on country and currency of most recent donation information?

@ppenloglou @Pcoombe this issue is back again, any new ideas on how to stop this with a combination of emails and donate wiki? Are emails still being sent with the amount of previous donations + country being hardcoded?

There are so many ways a country can change in Civi, including a donor changing it themselves via the Email Preferences form! The only bulletproof way to fix this is to start putting currency in any link that has an amount.

Apologies for responding late here. On your question @Cstone:

Are emails still being sent with the amount of previous donations + country being hardcoded?

Yes, that’s our current approach for using donate.wiki hyperlinks in emails. I believe the main challenge is that we can’t pass the currency through a URL parameter. Donate.wiki is built around a country-based structure, which also determines the currency, as @Pcoombe has noted.

Given the current setup, hardcoding the country seems to be the more reliable choice — at least when emailing a single-country audience — because we can reasonably assume that donors residing in that country gave in the corresponding currency. With geolocation enabled, however, we’ve seen cases where traveling donors getting a mismatch between their previous gift currency and the auto-selected one. This issue becomes more significant when the two currencies differ substantially in value (eg. USD / JPY is a much bigger problem compared to USD / EUR).

That said, the current method isn’t foolproof either, as we’ve seen in the examples above...

Are there plans to update donatewiki to allow passing a currency code? Or at least some code to ignore unreasonably large amounts that may have been from other currencies?

Edit - @Cstone just let me know about the plan to pass a currency code in the email link and use it to check whether it matches the country. Sounds great!

Okay, based on a conversation with @ppenloglou earlier we can include the highest previous contribution currency in the email links to donatewiki. I added a check in the javascript, if the hpcCurrency parameter doesn't match the form currency, then it won't make any changes to the amount options.

Example links assuming a past 5000 JPY donation

• Without currency specified (current behaviour)
  • Japan email (correct amount options) https://donate.wikimedia.org/?uselang=en&country=JP&hpc=5000
  • US email (very wrong amount options) https://donate.wikimedia.org/?uselang=en&country=US&hpc=5000
• With HPC currency specified
  • Japan email (correct amount options) https://donate.wikimedia.org/?uselang=en&country=JP&hpc=5000&hpcCurrency=JPY
  • US email (falls back to default US amount options) https://donate.wikimedia.org/?uselang=en&country=US&hpc=5000&hpcCurrency=JPY

Panos, could you look into adding this hpcCurrency parameter into email templates please?

Yes @Pcoombe and thank you for implementing this so quickly after discussing it! Very pleased with this 😄 I'll bring this back to email team, we should be able to start incorporating this very soon on our end.

Thanks @Pcoombe and @ppenloglou this looks like a good way to handle it