- User Since
- Oct 8 2014, 11:22 PM (441 w, 3 d)
- LDAP User
- MediaWiki User
- EEggleston (WMF) [ Global Accounts ]
Wed, Mar 22
In tech talk we were looking for payment confirmation notificationss and never got them either. We should ask dlocal if we need to make another API call to capture or something
Tue, Mar 21
maybe we could just do this instead: https://phabricator.wikimedia.org/T240581
Mon, Mar 20
ah, so we could potentially delete pending messages in the recurring queue consumer too, not just in the one-time queue consumer and payments-init
we should get the email from our status lookup API call
Fri, Mar 17
Thu, Mar 16
This is enabled in production, and DLocal have confirmed that all of the payment methods from the APIv1 account are enabled on the new account
I got this working on a single-donation run by deploying the correct credentials to SmashPig config. The old job is disabled and the new job should run every 10 minutes.
Wed, Mar 15
Thanks! So I think the payments-listener-smashpig log lines are all from frpig. I was talking about the log lines from payments* which are initiated by code in SmashPig-the-library and have SmashPig somewhere. Those are currently all going to payments-misc.
Spreadsheet with some links: https://docs.google.com/spreadsheets/d/1QbXZVJFdIzAhJgF8idkD7DCKMvdOyU2ON3BWQfenw6A/edit#gid=0
Etherpad with todos: https://etherpad.wikimedia.org/p/dlocal-deployment-todo
Tue, Mar 14
- On frpm, deployed credentials for dlocal to SmashPig and payments-wiki settings
- In merchant console, copied IP allowlist from other account to new account and filled in URLs
Mon, Mar 13
Moving this back to 'doing' because we have a new place to store it: contact.legal_identifier
Fri, Mar 10
This is deployed! Just needs a puppet update (see email) before we can create the process-control job to run jobs-dlocal.
So all we're lacking here is the logic to detect when a non-recurrable card has been used and avoid sending the recurring payment token in that case, so the donor gets the TY letter with 'one time' text.
Thu, Mar 9
Wed, Mar 8
Good point - we should clarify whether it's 24 or 48 hours, too! That's a good idea to set the next_scheduled_date earlier for these donations so they don't drift later and later each month. That would probably be easier to accommodate with the scheduler logic than to somehow pick up certain payment types before the date.
Tue, Mar 7
OK, we are setting the cookie attributes in production and the cookie is making it back to payments-wiki's return page.
Mon, Mar 6
Wed, Mar 1
New theory is that it's because of the cross-site POST (@Damilare was on the right track asking them to switch to GET!) and browsers getting more strict with when cookies are sent on cross-site requests.
Tue, Feb 28
Feb 17 2023
Feb 16 2023
Dropping this back in backlog because there's too much in progress in DonationInterface to touch the code without creating more merge conflicts