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

maybe we could just do this instead: https://phabricator.wikimedia.org/T240581

In T332637#8714979, @jgleeson wrote:

My current working assumption for this one is that when we get a rejection, we want to delete any relatd pending message and log the rejection.

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

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.

Post-meeting notes:

Thanks, @Dwisehaupt!

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

So far:

• 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

Moving this back to 'doing' because we have a new place to store it: contact.legal_identifier

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.

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.

OK, we are setting the cookie attributes in production and the cookie is making it back to payments-wiki's return page.

Related: T331319

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.

Dropping this back in backlog because there's too much in progress in DonationInterface to touch the code without creating more merge conflicts