We need two new items in the donor traffic lane for Portal and mobile app banners, which send traffic to donate-wiki.

I've recreated this locally. The issue is that it's never been implemented, so I've renamed the task from "fix" to "implement".

Problem: Choosing gateways for recurring donations

I've pushed a patch to filter payment methods by country and align it with the config discussion in the ComboWiki config doc.

1. Do you remember why you reverted to the key 'Donor'? Changing it might make our lives easier for combowiki. It's possible there is a good reason tho.
2. I'm inclined to avoid digging into the payment form internals for now. My vague memory is that we use XX just as a last resort. Since it's not blocking combowiki anymore, I'd frankly rather focus on combowiki for now, but we could ticket it and revisit it later. Does that sound ok?

@Laurabarluzzi the issue is that the payment forms can currently set values that are read by ComboWiki. If and when we retire the payment forms, as they are superseded by ComboWiki, that will no longer be a problem, but until then they both share the same 'Donor' session key, so it's conceivable that XX could make it into the session from a payment form session, which is then read into ComboWiki's state.

On the first question, Decide the ComboWiki country once, on the server answers it: we no longer set XX or leave the country empty. normalizeCountry() now uses a valid requested country (stored uppercase), then a valid GeoIP country, and finally defaults to US with a warning. Both XX and an empty country break gateway routing, which needs a country a gateway actually supports, so US gives routing and the form a real country while the donor can still change it with the country selector.

In T439255#12371091, @Laurabarluzzi wrote:

Do we know which currencies are supported via PayPal? Only USD? I see that also EUR is no supported when trying.

Maybe this phab is blocked by the ongoing configuration discussion in this google doc: https://docs.google.com/document/d/1Td22RN8TWjIYXDhLLk4U_bPyY6DAxzv3YFWWBWfeCQk/edit?tab=t.0#heading=h.423wkyit4lz

@Ejegg I think I have a compromise between a single recurring threshold (which would also hide spikes in other codes) and per-code thresholds or rate-based checks (more work). We already have ignore_list, which applies to all charges. We could add a second list that only applies to recurring charges, so we can suppress the card churn codes on the nightly run while other recurring errors, fraud included, still alert at the normal threshold:

Some info on the "Contract not found" errors https://help.adyen.com/knowledge/ecommerce-integrations/error-codes/why-do-i-receive-a-800-contract-not-found-error

Also, we had 338 recurring failures last night alone, 228 of them invalid_payment_method responses. If we tried to quiet these with the recurring bucket, the threshold would need to be up around 200, which feels high.

Thanks @Laurabarluzzi. I read over the ticket, and I can see you drilled into one of the affected transactions from an earlier batch.

I'm gonna dig into some of the contact records and charges related to the 224 invalid_payment_method failures

I looked into this using last night's run as a sample batch, and it looks like we processed 1,420 annual recurring charges last night, but 338 failed. That ~24% failure rate seems high.

Thanks for the bug report @Eileenmcnaughton. I'll try to fix it.

@Lars @AKanji-WMF I've reviewed this task, and I feel more comfortable with the risk profile. The proposed civiproxy endpoint takes an email address as input, so to exfiltrate anything, an attacker would already need to know donors' email addresses and be able to reach the endpoint from Zendesk's IPs. That means a meaningful breach would have had to occur already, and this endpoint wouldn't be the weak link.

Ok, after revisiting this 2 weeks later, we are now going to rely on the gateway adapters under the hood, so we should get the contribution tracking plumbing for free so I think we can close this.

patch here https://gerrit.wikimedia.org/r/c/wikimedia/fundraising/dev/+/1304850