We seem to get this error when a donor gets a new contribution tracking ID but we don't regenerate the order ID. Make sure we're regenerating the order ID when a new contribution tracking ID is generated.
Some id pairs from failmails:
175206218:175204848.1
175206292:175199518.1
I looked into 175199518:175199518.1 / 175206292:175199518.1
It looks like the donor first attempted a PayTM recurring donation at 9:16 am UTC:
Apr 17 09:16:14 payments1007 SmashPig-Dlocal: dlocal::175199518:175199518.1 | Outbound data: '{"amount":"520.00","currency":"INR","country":"IN","order_id":"175199518.1","payer":{...},"description":"Wikimedia 877 600 9454","callback_url":"https:\/\/payments.wikimedia.org\/index.php?title=Special:DlocalGatewayResult&order_id=175199518.1","notification_url":"https:\/\/paymentslistener.wikimedia.org\/dlocal","payment_method_id":"PW","payment_method_flow":"REDIRECT"}'This donation attempt then sits at PENDING, and it looks like the donor doesn't isn't redirected back from the PayTM flow. We eventually get a REJECTED IPN back the following day for this attempt.
However, before that, the donor comes back at 10:23am UTC and retries a PayTM recurring donation:
Apr 17 10:23:46 payments1007 SmashPig-Dlocal: dlocal::175206292:175199518.1 | Outbound data: '{"amount":"520.00","currency":"INR","country":"IN","order_id":"175199518.1","payer":{...},"description":"Wikimedia 877 600 9454","callback_url":"https:\/\/payments.wikimedia.org\/index.php?title=Special:DlocalGatewayResult&order_id=175199518.1","notification_url":"https:\/\/payments-listener.wikimedia.org\/dlocal","payment_method_id":"UI","payment_method_flow":"REDIRECT"}'The Order ID is the same across both attempts.
I've recreated this locally by pressing the back button after the dLocal redirect. From there, when I redirect again back to the callback URL, I see a new ct_id using the old order_id. However, it's hard to know exactly what the donor sees during this scenario, as dLocal provides a sandbox console with predefined redirect options, which is not the same as the actual PayTM/UPI UI experience.
We could fix this by checking that the order id before the sequence matches the ct_id earlier in the flow.
Nice find! Can you tell why the ct_id is being cleared out and the order_id is kept? We could also trigger a recalculation of the order id every time we assign a new ct_id.
Change 917947 had a related patch set uploaded (by Jgleeson; author: Jgleeson):
[mediawiki/extensions/DonationInterface@master] WIP/BROKE: Add method to resolve the rare OrderId / ct_id mismatches
Change 919395 had a related patch set uploaded (by Jgleeson; author: Jgleeson):
[mediawiki/extensions/DonationInterface@master] WIP: Test for new method to resolve the rare order_id / ct_id mismatches
Change 917947 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add method to log the rare order_id / ct_id mismatches
As I was drafting an email to dLocal on this, I noticed that in some cases, we're getting the order_id POSTed back to us and not in the query string. This made me curious as to whether dLocal is somehow performing a POST redirect. I think that can happen with 307 redirects, but I couldn't figure out a way to confirm this.
Sample:
Jun 11 23:58:51 payments1007 dlocal_gateway: 177418067:177418048.1 order_id / ct_id mismatch detected Jun 11 23:58:51 payments1007 dlocal_gateway: 177418067:177418048.1 Array ( [amount] => post [amountGiven] => [amountOther] => [appeal] => [color_depth] => [contact_id] => post [contact_hash] => post [email] => post [emailAdd] => [encrypted_card_number] => [encrypted_expiry_month] => [encrypted_expiry_year] => [encrypted_security_code] => [firs t_name] => post [first_name_phonetic] => [gateway_session_id] => [java_enabled] => [last_name] => post [last_name_phonetic] => [screen_height] => [screen_width] => [st reet_address] => [supplemental_address_1] => [time_zone_offset] => [city] => [state_province] => [postal_code] => [phone] => [country] => get [card_num] => [expi ration] => post [cvv] => [currency] => get [currency_code] => [payment_method] => post [payment_submethod] => post [recurring_payment_token] => [issuer_id] => [order_id] => post [subscr_id] => [referrer] => post [utm_source] => post [utm_source_id] => [utm_medium] => post [utm_campaign] => post [utm_key] => [language] => post [uselan g] => get [wmf_token] => post [data_hash] => post [action] => [gateway] => post [descriptor] => [account_name] => [account_number] => [authorization_id] => [bank_ch eck_digit] => [bank_name] => [bank_code] => [branch_code] => [country_code_bank] => [date_collect] => [direct_debit_text] => [iban] => [fiscal_number] => [trans action_type] => [processor_form] => post [recurring] => post [recurring_paypal] => [redirect] => [user_ip] => [server_ip] => [variant] => post [opt_in] => [employe r] => [employer_id] => [payment_token] => [full_name] => [upi_id] => [initial_scheme_transaction_id] => )
The fact that some order_ids are coming back POSTed challenges the original explanation of this problem only happening due to the redirect URL containing an order_id that relates to an expired/lost session.
However, there are still cases where the order_id IS sent back on the query string.
Example:
Jun 12 05:22:01 payments1005 dlocal_gateway: 177421101:177421088.1 order_id / ct_id mismatch detected Jun 12 05:22:01 payments1005 dlocal_gateway: 177421101:177421088.1 Array ( [amount] => [amountGiven] => [amountOther] => [appeal] => [color_depth] => [contact_id] => [contact_hash] => [email] => [emailAdd] => [encrypted_card_number] => [encrypted_expiry_month] => [encrypted_expiry_year] => [encrypted_security_code] => [first_name] => [first_name_phonetic] => [gateway_session_id] => [java_enabled] => [last_name] => [last_name_phonetic] => [screen_height] => [screen_width] => [street_address] => [supplemental_address_1] => [time_zone_offset] => [city] => [state_province] => [postal_code] => [phone] => [country] => [card_num] => [expiration] => [cvv] => [currency] => [currency_code] => [payment_method] => [payment_submethod] => [recurring_payment_token] => [issuer_id] => [order_id] => get [subscr_id] => [referrer] => [utm_source] => [utm_source_id] => [utm_medium] => [utm_campaign] => [utm_key] => [language] => [uselang] => [wmf_token] => get [data_hash] => [action] => [gateway] => [descriptor] => [account_name] => [account_number] => [authorization_id] => [bank_check_digit] => [bank_name] => [bank_code] => [branch_code] => [country_code_bank] => [date_collect] => [direct_debit_text] => [iban] => [fiscal_number] => [transaction_type] => [processor_form] => [recurring] => [recurring_paypal] => [redirect] => [user_ip] => [server_ip] => [variant] => [opt_in] => [employer] => [employer_id] => [payment_token] => [full_name] => [upi_id] => [initial_scheme_transaction_id] => )
This is hurting my head.
Change 932353 had a related patch set uploaded (by Ejegg; author: Ejegg):
[mediawiki/extensions/DonationInterface@master] A bit more debug logging
Change 932353 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] A bit more debug logging
Change 959061 had a related patch set uploaded (by Ejegg; author: Ejegg):
[mediawiki/extensions/DonationInterface@master] DLocal: Avoid duplicate order IDs
Change 959061 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] DLocal: Avoid duplicate order IDs
Change 960709 had a related patch set uploaded (by Wfan; author: Jgleeson):
[mediawiki/extensions/DonationInterface@master] Add unit test for 'DLocal: Avoid duplicate order IDs' fix
Change 960709 merged by jenkins-bot:
[mediawiki/extensions/DonationInterface@master] Add unit test for 'DLocal: Avoid duplicate order IDs' fix
Change 919395 abandoned by Jgleeson:
[mediawiki/extensions/DonationInterface@master] WIP: Test for new method to resolve the rare order_id / ct_id mismatches
Reason: