Consider if we need to do anything differently due to dlocal payload differences.
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T384967 Gravy Dlocal | |||
| Resolved | Damilare | T385016 Gravy dLocal Webhooks | |||
| Open | Damilare | T386965 Gravy notifications on refunds initiated in Dlocal dashboard. |
Event Timeline
Note: Dlocal currently allows only one webhook URL for each class of notifications. Setting Gravy's url would mean we miss out on notifications for our direct connection.
We currently specify the notification url to use for new payments in the Dlocal transaction request for the direct connection, looks like Gravy does the same also and we might not need to do any extra bit there.
Refunds and Chargebacks are the only one's hard coded in the Dlocal console. Though refunds for transactions initiated on Gravy should be carried out in the Gravy console, the gravy transactions can also be refunded directly on Dlocal. Initiating a refund for a gravy transaction on the dLocal console sends a similar message as that of the direct connection, the only difference is that Gravy uses a different order_id syntax.
Here are two refund messages for transactions from the two connections:
Refund on transaction from direct connection:
{"id":"REF-2486-f7e6cd78-cb42-4f21-a1da-a8ccc19942a3","payment_id":"R-2486-56553ea5-a986-48cc-8f10-3d3cba174d3b","notification_url":"https://paymentsipntest3.wmcloud.org/dlocal","amount":6000.00,"currency":"COP","description":"[Requested via Dashboard] ","id_payment":"R-2486-56553ea5-a986-48cc-8f10-3d3cba174d3b","status":"PENDING","status_code":100,"status_detail":"The refund is pending.","created_date":"2025-02-18T17:45:20.000+0000","amount_refunded":0.00,"use_orig_fx":false,"payment_request_amount":6000.00,"payment_request_currency":"COP","transaction_id":"486.1","document_number":"9999999999","order_id":"486.1"}Refund on transaction from gravy connection:
{"id":"REF-2486-92ae3ed5-a4f3-440d-8d73-34e5d5d03986","payment_id":"R-2486-03fb8ce0-c03a-4626-b798-a461182ddf24","notification_url":"https://paymentsipntest3.wmcloud.org/dlocal","amount":6000.00,"currency":"COP","description":"[Requested via Dashboard] ","id_payment":"R-2486-03fb8ce0-c03a-4626-b798-a461182ddf24","status":"PENDING","status_code":100,"status_detail":"The refund is pending.","created_date":"2025-02-18T17:43:31.000+0000","amount_refunded":0.00,"use_orig_fx":false,"payment_request_amount":6000.00,"payment_request_currency":"COP","transaction_id":"4RgrbpIZ8j98MA0HVMcLnB","document_number":"9999999999","order_id":"4RgrbpIZ8j98MA0HVMcLnB"}Another issue is that Gravy generates a different webhook urls for every Dlocal payment method added, thereby complicating the issue even further. I've reached out to Gravy for insights to how this can be simplified.
I have confirmed that notifications for the following Dlocal transactions initiated on Gravy are received on our sandbox listener:
- Payment Authorised for card payments
- Payment captured for all payment types
- Refunds initiated on Gravy dashboard.
Moving this to done since the bug described earlier is minor. Especially since we can train people on how to identify Gravy transactions and avoid refunding them on the dLocal dashboard. I created T386965 to follow up with Gravy on a fix.