Page MenuHomePhabricator

Odd dlocal recurrings
Open, HighPublic

Description

I found 2 * dlocal recurrings that seem like duplicates? The 14 May 2025 transaction was inserted to CID 59699477 on 2025-11-05 02:11:21 but it already existed (I think) on duplicate contact 63251566 - although details differ a little - they came up due to lack of link to contribution_tracking

59699477 DLOCAL T-648-08181275-fedc-43f1-8bb2-dc3ca4e4b819
63251566 RECURRING DLOCAL T-648-b1df382b-c842-4856-9683-b3f17523e57c

The other one is

https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=31284367 with the 2 May donations

Event Timeline

@Ejegg just thought I'd check this one with you - they might be fine - in which case we can just merge the first contact & close but they seem kinda suspicious

Good catch - looks like T-648-08181275-fedc-43f1-8bb2-dc3ca4e4b819 is the ID associated with the capture and T-648-b1df382b-c842-4856-9683-b3f17523e57c is the ID associated with the authorization.

The donor was on our site at 1:30 PM and the donation went to the pending queue.
Then it was resolved by the pending transaction resolver which sent it to the donations queue at 14:30 with the 'b1d' ID.

The other ID maybe came from the INVALID_RECURRING damaged queue messages that I requeued yesterday. Looking for more info in the logs.

XenoRyet triaged this task as High priority.Dec 8 2025, 9:05 PM
Ejegg removed Ejegg as the assignee of this task.Mar 10 2026, 9:31 PM
Ejegg moved this task from In Progress to Backlog on the Fundraising Tech - Chaos Crew board.

The May 7th 2025 transactions are in Civi as these two: https://civicrm.wikimedia.org/civicrm/contact/view?reset=1&cid=31284367

  • The Recurring Gift Transaction ID RECURRING DLOCAL T-648-a0727561-0be4-4e37-81d2-43344adb5538 with status = Complete
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:33:29 civi1002 SmashPig-ConsumePendingQueue: SPCID-1688022060 | Storing message with gateway 'dlocal', order ID '230766777.1', and gateway txn id 'T-648-a0727561-0be4-4e37-81d2-43344adb5538' in database |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:33:46 civi1002 SmashPig-ConsumePendingQueue: SPCID-1688022060 | Storing message with gateway 'dlocal', order ID '230766777.1', and gateway txn id 'T-648-a0727561-0be4-4e37-81d2-43344adb5538' in database |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:34:01 civi1002 SmashPig-Dlocal-QueueJobRunner: SPCID-0043715042 | (corr_id-dlocal-T-648-a0727561-0be4-4e37-81d2-43344adb5538) Found token from AUTHORIZED status message on 'T-648-a0727561-0be4-4e37-81d2-43344adb5538' and order ID '230766777.1'. |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:34:01 civi1002 SmashPig-Dlocal-QueueJobRunner: SPCID-0043715042 | (corr_id-dlocal-T-648-a0727561-0be4-4e37-81d2-43344adb5538) Attempting to locate associated message in pending database |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:34:01 civi1002 SmashPig-Dlocal-QueueJobRunner: SPCID-0043715042 | (corr_id-dlocal-T-648-a0727561-0be4-4e37-81d2-43344adb5538) A valid message was obtained from the pending queue |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:34:01 civi1002 SmashPig-Dlocal-QueueJobRunner: SPCID-0043715042 | (corr_id-dlocal-T-648-a0727561-0be4-4e37-81d2-43344adb5538) Updating message in pending database |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 17:35:02 civi1002 civicrm.wmf[2246781]: civicrm.wmf.INFO: PaymentsInitQueueConsumer array{"validation_action":"process","payments_final_status":"pending","payment_submethod":"visa","country":"BR","amount":"10.00","currency":"BRL","date":1746639225,"server":"payments1005","gateway":"dlocal","gateway_txn_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","contribution_tracking_id":"230766777","order_id":"230766777.1","payment_method":"cc","source_name":"DonationInterface","source_type":"payments","source_host":"payments1005","source_run_id":2494608,"source_version":"822bac34b64b0cce0b0d916c8ae139fe809b100f","source_enqueued_time":1746639225} {"class_name":"PaymentsInitQueueConsumer","message":{"validation_action":"process","payments_final_status":"pending","payment_submethod":"visa","country":"BR","amount":"10.00","currency":"BRL","date":1746639225,"server":"payments1005","gateway":"dlocal","gateway_txn_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","contribution_tracking_id":"230766777","order_id":"230766777.1","payment_method":"cc","source_name":"DonationInterface","source_type":"payments","source_host":"payments1005","source_run_id":2494608,"source_version":"822bac34b64b0cce0b0d916c8ae139fe809b100f","source_enqueued_time":1746639225}} []
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:03 civi1002 civicrm.wmf[2301835]: civicrm.wmf.INFO: Resolving pending transaction: {"gateway_txn_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538" [....]

This shows that we set gateway_txn_id with T-648-a0727561-0be4-4e37-81d2-43344adb5538 that as of this point it was only the ID from the transaction type "authorization".

  • One-time Transaction ID DLOCAL T-648-47c8f056-ac06-4499-862e-61d3a45cad24 with status = Complete
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 SmashPig-Dlocal: * h2h3 [:path: /payments/T-648-a0727561-0be4-4e37-81d2-43344adb5538/status]
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 SmashPig-Dlocal: > GET /payments/T-648-a0727561-0be4-4e37-81d2-43344adb5538/status HTTP/2\x0d
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 SmashPig-Dlocal: pending_transaction_resolver | Raw response from dlocal: {"id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","status":"AUTHORIZED","status_detail":"The payment was authorized.","status_code":"600"} |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 SmashPig-Dlocal: pending_transaction_resolver | Outbound data: '{"authorization_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","amount":"10.00","currency":"BRL","order_id":"230766777.1"}' |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 SmashPig-Dlocal: pending_transaction_resolver | Raw response from dlocal: {"id":"T-648-47c8f056-ac06-4499-862e-61d3a45cad24","amount":10.00,"currency":"BRL","country":"BR","created_date":"2025-05-07T18:30:04.000+0000","approved_date":"2025-05-07T18:30:04.000+0000","status":"PAID","status_detail":"The payment was paid.","status_code":"200","order_id":"230766777.1","description":"Wikimedia Foundation (Recurring)","notification_url":"https://payments-listener.wikimedia.org/dlocal","authorization_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538"} |  | 
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:30:04 civi1002 civicrm.wmf[2301835]: civicrm.wmf.INFO: Pending transaction 230766777.1 was resolved and the result is {"email":"xxx","gateway_txn_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","status":"complete","risk_scores":[]} [] []
/srv/archive/frlog1002/logs/fundraising-misc-20250508.gz:May  7 18:31:01 civi1002 civicrm.wmf[2302991]: civicrm.wmf.INFO: PaymentsInitQueueConsumer array{"gateway_txn_id":"T-648-a0727561-0be4-4e37-81d2-43344adb5538","contribution_tracking_id":"230766777","country":"BR","currency":"BRL","gateway":"dlocal","order_id":"230766777.1"

Both dLocal pages shows the other ID in the Related Transaction section; what might have happened is that dLocal might have sent (and maybe still send) 2 transaction IDs; one is type "authorization" and the other one is type "capture" and we stored the first ID and didn't updated in the pending_transaction_resolver when we got the raw response from dlocal with the new ID and status "paid"; is this the bug? Shouldn't this affect all users though? But my understanding is that we sent the request with the id X and got back id Z with status paid (what we want to store in the donation) and we could update in place the id from x to z since we sent x to the request payload, so they are "related" in dLocal. Is my understanding incorrect? Should we fix this?

Another couple of things I didn't investigate but look odd are:

So I wonder if this civi contact recurring was affected by this bug, the initially recurring authorization was for recurring but then turned into one-time in the UI. However in session we kept recurring true, and so we believed this payment came through as a first installment and tried to charge again but always got rejected because the user didn't actually setup the recurring installments in dLocal? Just guessing here.