I have a number of customers that have been performing me-to-me payments. These go from a verified source, to an unverified source, All belonging to them. So this ends up being a multi-leg ACH where the first leg goes from the verfieid source, to Balance, then the second ACH goes from Balance to the unverified source. We have a tracking system that tracks the entire process, and relies on the funded-transfer fields to be present.
So I have two transfer IDs. first and second ACH payments
de4f6a6c-6753-f011-ac7e-0a27ad48efdb
aaeafb51-a455-f011-ac7e-0a27ad48efdb
When I do a query for the first transfer, I can see it contains the proper funded-transfer field, which points to the second ach payment
However, looking at the webhook logs, when the first ACH payment is queried, its missing the funded-transfer field, and the payment is being mis-classified.
Its very important that the transfer queries have full information for obvious reasons. Can you please check with the dev team to see why these fields would be missing? It seems to be happening with all payments, being processed as of this month. Our payment tracking system is going haywire, and we’re having trouble tracking payment flows.
spencer
(Spencer Hunter - Lead Developer Advocate @ Dwolla)
2
Hi @lucio , Thanks for reaching out and for providing the detailed explanation with the specific transfer IDs. I completely understand how important it is for your payment tracking system to get complete data in a timely manner. My hunch is that it’s a timing issue with the webhook being fired before the secondary transfer is created. When the first leg of the payment (from the customer’s verified bank to their Dwolla Balance) completes, we immediately send a customer_bank_transfer_completed webhook for that transaction. At that exact moment, the second leg of the payment (from the Dwolla Balance to the unverified source) is initiated, but the link between the two transfers may not have been established in our system yet and be available in the API.
It sounds like your app is querying the first transfer immediately after receiving its completion webhook. At this point, the funded-transfer field hasn’t been populated yet because the second transfer is still being created. When you check the transfer manually later, enough time has passed for the second transfer to be created and linked, which is why you see the funded-transfer field as expected.
I’ll open up a ticket with our engineering team for further investigation to identify if that’s the issue and if any changes can be made on our end. In the meantime, could your app treat this as an error and retry the API call to see if a small delay helps with availability of the funded-transfer?
I’ll open up a ticket with our engineering team for further investigation to identify if that’s the issue and if any changes can be made on our end. In the meantime, could your app treat this as an error and retry the API call to see if a small delay helps with availability of the funded-transfer?
That would introduce a huge level of complexity to the event processing. It would be better if the webhooks could just revert to its original behavior. We have spent years tuning our handlers to track your payment system, and it is extremely disruptive to chase random changes over time.
This change in the timing must have been pushed out in this past month. ALL our payment tickets are currently failing to track the second leg of their transactions. I urge you to revert the webhooks to their original behavior. We just don’t have resources to handle these changes. Until we get a fix, our payment tracking is simply not working properly.
Thanks again for your patience while our engineering team investigated this issue in depth. We’ve now completed a full review and can confirm that there have been no recent changes to our webhook behavior or transfer processing logic that would account for this shift. Additionally, we found no evidence of degradation or regressions on our side.
What we’ve identified is that this behavior stems from a race condition inherent in the timing of your integration logic. Specifically, the issue occurs when your system attempts to retrieve the funding transfer before the corresponding funded transfer has been created.
To explain further: the funded transfer is created during our internal job that run every business day which marks transfers as processed as per the ACH transfer timeframe. The time it takes to complete this process can vary depending on factors like queue depth or system load. This means there’s no guaranteed timing on when the funded transfer will appear—sometimes it’s nearly instant, other times there may be a delay of several seconds or more.
Recommendations
To address this, we’d recommend one of the following approaches:
Retry Logic: Implement a retry if the funded-transfer link is not present. Introducing a delay of 1–2 minutes (or more, for added safety) before retrying the transfer query should help ensure the data is available.
Alternative Linking Strategy: Consider shifting to a more resilient strategy by tracking the relationship in the other direction. When receiving the customer_bank_transfer_created webhook for the second leg, you can look up the original funding transfer via the funding-transfer field present on that transaction and link them that way.
Using correlationId: You could also use the correlationId as a way to link the funding-transfer to the funded-transfer resource. This value that your app provides when creating a transfer is present in the transfer resources as well as the webhook payloads of all legs of the transfer.
We truly understand how disruptive this has been for your tracking system and we empathize with the effort your team has put into building around this behavior. Unfortunately, because this is not caused by a change or regression in our platform, there’s nothing we can revert on our side. That said, we’re committed to helping you through this and happy to support as you implement any of the recommended adjustments.
Let us know how we can assist further as you adapt—whether it’s with technical guidance or testing support!