Possible rate-limiting issue in UAT environment

(Jzeal) #1

I’m building a simple “batch payment” system using the PHP DwollaSwagger library. The meat of the project is “authenticate with Dwolla, retrieve the payer’s primary funding source on file, then loop through a database table full of people who need payments.”

The authentication and funding source retrieval works fine.

However, the “loop through payments” seems to behave erratically at best. If I have, say, twenty transfers queued, one or two may complete successfully, and the rest will lthrow an exception with a message like

[500] Error connecting to the API (https://api-uat.dwolla.com//transfers)

If I var_dump the exception, I’ll see messages like

A server error occurred. Error ID: 4d0a947d-176f-4567-9840-83dfc6856242. (always a different GUID; that’s a sample).

If I get a successful transaction in one batch, odds are the next few batches will fail 100%. This makes me think we’re hitting some sort of rate-limiting behavior-- some firewall somewhere is saying “Your server is pounding us, better cut you off for a few hours…”

I can’t find any hard information about a rate limit for submitting payments.

Before you ask, why am I not using Mass Pay? When the project started, the MassPay component wasn’t even available in the SDK. Also, for our tracking purposes, it’s probably more useful to get individual transaction IDs to work with up front, rather than having to retrieve a Job ID and come back later to get its details. Once we’ve got it working the “stupid” way we can look at something more sophisticated.

(Spencer Hunter) #2

Hey @jzeal, We don’t impose rate limiting at this time, however you may run into this error when trying to send too many balanced sourced transfers at one-time. (Note: This is not only limited to UAT) Part of the reason we created the MassPay API was to offload work that your app would have to do in queuing/processing one to many transactions.

If you don’t want to integrate with our MassPay API then I’d recommend either waiting for a response before initiating another transfer or bump back the queuing time on your end for initiating requests to the API.