Webhook delivery delays and timeout issues during high-load mobile testing?

General
1

Hi everyone,
I’m currently in the middle of testing our Dwolla API integration for a mobile-first marketplace, and I’ve run into a bit of a performance wall that I’m hoping someone can shed some light on. We are using the sandbox environment to test various transfer statuses, but I’ve noticed that our webhook listener occasionally drops notifications when the testing device is under a heavy process load.

Lately, I’ve been running some automated background tasks and testing the limits of our mobile environment using some blox scripts to see how the device handles concurrent script execution while waiting for a payment status update. It seems like as soon as the background script activity spikes, the HTTP requests from our listener either timeout or the device fails to process the incoming webhook payload in time.

Has anyone else noticed their mobile-based listeners or client-side status polling getting throttled when there are other intensive executors running in the background? I’m trying to determine if I should be increasing our server-side timeout settings or if there’s a better way to ensure the Dwolla notifications take priority over other local script execution. I’m really worried that if a user is multitasking or running other heavy tools, they might miss a critical “transfer completed” notification.

Any advice on how to stabilize the connection and ensure consistent webhook processing during high-resource usage would be a huge help!

2

Hi @huo900! Shreya from Dwolla’s DevRel team here. Thanks for posting!

What you’re seeing is a common issue when webhook listeners are running in environments under heavy load.

A few best practices from our docs may help:

1. Keep the webhook handler lightweight
Your endpoint should do minimal work before responding. We recommend validating the request and immediately returning a 200 OK, then processing the payload asynchronously.

2. Use a queue for processing
A typical pattern is:

Dwolla webhook → webhook endpoint → queue → background worker

The endpoint acknowledges the request quickly while the worker handles heavier processing (DB updates, notifications, etc.).

3. Respond within 10 seconds
Your endpoint must return a 2xx response within 10 seconds. If it doesn’t, the delivery is considered a failure and Dwolla will retry automatically (up to 8 times over ~72 hours).

4. Handle duplicates and ordering
Webhooks are asynchronous and may arrive out of order or be retried, so your processing should be idempotent.

5. Avoid mobile/client-side listeners
Running a webhook listener on a mobile device or heavily loaded client can lead to timeouts like you described. Webhook endpoints should run on a stable server-side service, with the mobile app receiving updates from your backend.

Summary: host the webhook on a server, return 200 OK quickly, and queue the event for background processing. This will make webhook handling much more reliable during high resource usage.

Hope this helps! Please let us know if you have any questions on any of the above!

Webhook delivery delays and transfer state inconsistency in high-concurrency mobile environments
3

Hey, I’ve run into something similar while stress-testing webhook flows, and what you’re describing usually ends up being more about the client-side environment than Dwolla itself.

If your listener is running on a mobile device (or anything resource-constrained), heavy background scripts can easily starve the event loop. When that happens, the webhook request might actually arrive, but the app doesn’t process it in time, or your HTTP handler can’t respond within the expected window—so it looks like a “dropped” notification.

A few things that helped in my case:

  • Move webhook handling off the mobile layer entirely if possible. Treat the mobile app as a viewer, not the receiver.

  • Use a backend endpoint + queue (SQS, RabbitMQ, Redis queue, etc.) so the webhook is acknowledged instantly (HTTP 200 fast), then processed asynchronously.

  • Keep webhook responses ultra-fast—Dwolla (like most providers) expects quick ACKs; long processing inside the request = timeouts under load.

  • Assume retries will happen and make processing idempotent so nothing breaks if a notification is delayed or duplicated.

  • If you must test on-device, try reducing concurrent background tasks or simulate load on a separate thread/process so it doesn’t block the network handler.

In short: don’t try to “prioritize” webhooks on a busy mobile runtime—offload and queue them server-side so they’re resilient no matter what the client is doing.