Page MenuHomePhabricator

Dlocal cancel buttons don't go back to the payments wiki form
Closed, ResolvedPublic1 Estimated Story Points

Description

Looking at #2, 3 and 8 here

https://docs.google.com/presentation/d/1W8iWi0Ti1oIBKQU6oiA97d9JOQdTYcV4repHx8pdOZY/edit#slide=id.g5e19cbd41d_0_17

This is probably related to T131401 we need to know if we can make any changes here or if this is just on dlocal.

Do we want to discuss this with Dlocal further? They are happy to talk to us about a workaround but as of today they cannot send back two codes to enable us to send the donor back to the payments page. Do we want to discuss a work around or leave as is? Notes from discussions:

7/30/2019
2
ICancel/Continue redirect
https://phabricator.wikimedia.org/T229336
From slide screen captures: #8, #2 ‘Cancel’ and ‘Continue’ buttons takes to the Thank You Page. Should take donor back to payments page (link above)

Looks like for credit cards, back when fixing T131401, they changed something on their end to kick back a failure code on cancel, so that we at least send donors to the fail page rather than the thank you page. That behavior is still present on the cc forms. One would assume they could do the same for the BT forms. It doesn't look like we ever got them redirecting back to the payments page, but it's been a while so we can ask if that's possible.

8.14 under investigation as turned around to DLocal only on 8.12

Notes from 8.16 When cancel we do not want user returned to TY page. We want two different return codes, error codes, no TY page redirection when canceled.

9.12 Wikimedia needs to brainstorm a work around with Dlocal because we can’t provide two codes without effecting your entire customer base.
11 b.
7/30/2019
2
Cancel redirect
From slide screen captures #3 CANCEL button takes to the Thank You Page. Should take donor back to payments page (link above)

Looks like for credit cards, back when fixing T131401, they changed something on their end to kick back a failure code on cancel, so that we at least send donors to the fail page rather than the thank you page. That behavior is still present on the cc forms. One would assume they could do the same for the BT forms. It doesn't look like we ever got them redirecting back to the payments page, but it's been a while so we can ask if that's possible.

8.1`4 under investigation as turned around to Dlocal only on 8.12
8.21.2019 DLocal to consider a way to send
8.28.2019 If we change the code we are sending it will change every merchant on the current version of API. Dlocal can only provide only one notification type. Should we have Elliott speak to Seba again on a one-off workaround.

Event Timeline

DOD: is this on dlocal side? If so, what would we say back to dlocal to help them identify the issue?

Yea, this is on dLocal's side.

Looks like for credit cards, back when fixing T131401, they changed something on their end to kick back a failure code on cancel, so that we at least send donors to the fail page rather than the thank you page. That behavior is still present on the cc forms. One would assume they could do the same for the BT forms. It doesn't look like we ever got them redirecting back to the payments page, but it's been a while so we can ask if that's possible.

XenoRyet changed the point value for this task from 0 to 1.Aug 20 2019, 8:04 PM

Can you provide me the code we are receiving so I can get to DLocal?

8.28.2019 Following call with Elliott, Pats, and DLocal of 8.22, DLocal advise that they cannot provide two distinct codes back to Wiki as it will impact all users on their API. They are happy to discuss a one-off work around for us on this. Please advise if you would like me to setup another call to see what can be done.

EMartin updated the task description. (Show Details)

I see this got reopened. This doesn't seem actionable on our end any time soon. We could meet with them at some point but it's pretty clear they need to do some work on their end.

yes, before I let this go dormant, i wanted to know if we wanted to have a
further conversation with them to find a work around for this. If not,
I'll park it but it never got resolved as the status indicated so thought
it worth the question. thanks

Aklapper added a subscriber: XenoRyet.

Removing task assignee due to inactivity, as this open task has been assigned for more than two years. See the email sent to the task assignee on February 06th 2022 (and T295729).

Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.

If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".

Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.

EMartin claimed this task.