OK, patch is updated to handle email addresses as proposed in the previous comment.

I'm not finding that one specifically, but I do still see some instances of that error, all from donors who use a + sign in their email address. We can collect their full email address for ourselves and just send DLocal a version with everything from the + sign to the @ sign stripped out.

Looks like the audit parser is incorrectly tagging some donations as legacy 'paypal' instead of 'paypal_ec'. Since we search for existing transactions based on the processor tag plus the processor-side id, this incorrect processor tag makes it look like a new donations.

OK, this is fixed. The puppet config keys had changed. We needed to change it to

profile::ssh::server::gateway_ports: true

Well darn, gatewayports isn't working any more! forwarding.conf exists in the sshd_config.d directory with that option, but the main config file has lost the line to include things from that subdirectory.

Oops, we actually do need this to deploy the GatewayChooser refactor. When I tried deploying it without this, we were wrongly denying a lot of South American PayPal donors.

I was mucking about in the payment instruments to fix the audit parser, so I went ahead and added these BT methods too

Heh, I think one is long since solved

This should be easy enough. I see that we have a bunch of other bank transfer methods that are not broken out individually either. Only the India ones have their own payment method defined and the rest are lumped under 'Bank Transfer'. Should we break out all the other D*Local bank transfer methods in CiviCRM too?

OK @EMartin, this is all set

Nice, they're all now COLLATE=utf8mb4_unicode_ci

This was added by Donor Relations somewhere along the line

Darn, this seems to be another case where sandbox and production have different rules. I'm seeing errors in the logs saying empty param x_city. I'm rolling back just this patch for now.

@EMartin this is deployed

No, we're not blocked. I just assume that folks from countries without AVS would be less likely to have their billing address in their Google Pay wallet and so our requiring it will be more friction for them. It may not turn out to be an issue, though - let's see what people say!

@EMartin can we cut one of the redundant 'keep or store' ?

Sure thing @EMartin . Would the pretest be US-only or are you thinking of doing other countries too?

If we're removing the address fields from the dlocal form completely (see T308464) that will also fix it, but I feel like we should add the + sign scrubbing as well in case they are used elsewhere.

I can trigger it if I put a plus sign in an street address or city. Maybe we can filter those out completely?

We could also remove it and replace Queue2civicrmTrxnCounter and the usages of report_metrics with Jack's StatsCollector code (https://github.com/jackgleeson/stats-collector)

Let's break this into 3 tasks:

• Move base queue consumer classes and their settings
• Move WMF transaction wrapper
• Move or remove date utilities

@DStrine for Peru and Mexico we have to generate random numbers so we don't trigger the DLocal-side fraud filters, but for India we have been able to send a constant ID with no problems. I guess they must have the same setting for ZA so this constant ID should hopefully be OK.

OK, default has been changed.

This is merged and ready to deploy as soon as the deployment script is working again

These have been removed on the IN credit card form

Peru cash:
https://payments.wikimedia.org/index.php?title=Special:AstropayGateway&appeal=JimmyQuote&payment_method=cash&recurring=&uselang=es-419&language=es-419&currency=PEN&amount=7&country=PE&ffname=astropay-pe&utm_campaign=internal_test

Thanks for clearing that up @EMartin - those should be simple to remove on payments-wiki too

Hmm, Amex seems to be failing with the same code. Maybe @EMartin can confirm with DLocal that we're supposed to be able to accept Diners and Amex in India?

The one triggering this seems to be 'Diners Club'