Thu, Jun 30
Tue, Jun 28
Thu, Jun 23
Wed, Jun 22
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
Tue, Jun 21
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.
Fri, Jun 10
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.
Thu, Jun 9
I was mucking about in the payment instruments to fix the audit parser, so I went ahead and added these BT methods too
Wed, Jun 8
Heh, I think one is long since solved
Jun 3 2022
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?
Jun 2 2022
OK @EMartin, this is all set
May 31 2022
Nice, they're all now COLLATE=utf8mb4_unicode_ci
This was added by Donor Relations somewhere along the line
May 27 2022
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
May 26 2022
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?
May 25 2022
May 24 2022
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?
May 23 2022
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
May 19 2022
@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.
May 18 2022
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
May 17 2022
May 16 2022
Thanks for clearing that up @EMartin - those should be simple to remove on payments-wiki too
May 13 2022
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'