Page MenuHomePhabricator

India - Dlocal/Wikimedia message trigger inquiry
Closed, ResolvedPublic


Triaging issues with Dlocal, we found a number of examples that seem to indicate something may be awry in our systemic communications with Dlocal. In the payments flow:
User - UPI pay page - Dlocal and then to Wiki page, we are questioning what occurs when Dlocal sends back an approved or rejected response. There is a thought that Wiki may be triggering something erroneously and may not be interpreting Dlocal's response correctly. This is due to messaging that signifies an error/reject but the funds have cleared. Here are a couple of merchant reference numbers where this has played out:

81567392.2 - approved instantly at Dlocal, but user received a reject error message
82244652.1 - approved but user receives an error message

Can we get insight on what we think we received on these transactions to trigger an unsuccessful response to the donor?

Event Timeline

Reedy renamed this task from India - Dlocal/Wikimeida message trigger inquiry to India - Dlocal/Wikimedia message trigger inquiry.Aug 4 2020, 5:26 PM

more info: the donor is seeing some sort of error. It looks like something on payments wiki. also they are not getting to the ty page.

This is the screenshot the donor in ZD 773751 saw around July 31.
Invoice# 82244652.1

image.png (459×677 px, 45 KB)

Sebastian wanted to know if WMF logs can provide any details about what caused us to show this message.

DStrine triaged this task as High priority.Aug 4 2020, 8:59 PM

Hi all, we have a meeting with Dlocal in the morning to discuss this. Would it be easier if someone from FRTech joined that call perhaps? 8:00am PT. Thurs August 6.

For both of the ct_ids listed in the ticket, the last line I see in the logs is us redirecting the donor to DLocal. This suggests that somehow the donor's session was expired by the time they got back to our site. There is definitely some logic to send donors with expired sessions to the TY page, but I'm not sure if it's working for DLocal. Will test that.

OK, so the vanilla dead session logic DOES work for DLocal, but I've found a bit more in the log file for 82244652.1 - there's one line with that order ID and a regenerated ct_id (82244999) saying 'country not set', and later the same second an exception creating the adaptor based on 'no currencies for <other country code>' (see T134214).

So it seems like this donor came in with country=IN on the querystring but on an IP address that geolocates to another country. This can be common for travelers - getting a main-cluster geolocation cookie set to one country and having it persist while they travel to another.

Then the donor had a dead session, but instead of us following the normal dead session logic we hit another exception based on their IP-geolocated country not having any currencies configured. If we solve T134214 I think that will also solve this ticket.

Change 619785 had a related patch set uploaded (by Ejegg; owner: Ejegg):
[mediawiki/extensions/DonationInterface@master] Stop currency exception in AstroPay constructor

new instance of this from today dLocal Invoice 89051187.1

Change 619785 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Stop currency exception in AstroPay constructor

OK, I've just deployed something that hopefully will fix these issues and get donors to the TY page even when they've got an IP address that geolocates to a country not configured for DLocal

yes, thank you @Elliott Eggleston <> !!