Hi everyone,
I’ve been integrating the Dwolla V2 API into a mobile-first marketplace application, and I’ve run into a specific edge case regarding webhook processing and transfer status synchronization that I’m struggling to stabilize.
I’ve noticed that when the mobile device initiating the transfer request is under heavy resource pressure—specifically when I’m running several background executors or testing the arceus roblox environment for its multi-threading capabilities—the app occasionally receives webhook events out of order or with significant latency. In some instances, the transfer_created webhook arrives after the transfer_processed one, or the local UI fails to update the “Pending” state because the background listener thread seems to be throttled by the mobile OS during these high-concurrency spikes.
While I was discussing these environmental bottlenecks with some other developers, we noticed that if the CPU load hits a certain threshold, the mobile network stack sometimes drops the initial ACK for the webhook, triggering multiple retries from Dwolla’s side. This has led to some concerns about idempotency—has anyone else noticed that their client-side state becomes “unsynced” or starts showing duplicate transfer entries if the device is multitasking heavily in the background?
I’m trying to figure out if I should be implementing a more aggressive local queuing system for these events or if there’s a way to prioritize the webhook listener thread to ensure we don’t miss status updates in “noisy” mobile environments. If you’ve dealt with maintaining payment state consistency on a device that’s being pushed to its limits—or have tips on handling out-of-order webhooks during heavy background processing—I’d really value your advice!
Best regards!