Microdeposit Salami Attack


In order to properly mitigate from micro-deposit salami attack, it would be beneficial to know the fingerprint of a bank ahead of time of initiating micro-deposits. (This assumes that once micro-deposit is initiated, there isn’t a way to cancel that)

This is my plan for the prevention:
The user initiates micro-deposit → Our server requests micro-deposit init to Dwolla → Our server gets a callback of the result. (succeeded or failed) → Check the fingerprint from the callback if it’s dupped → If dupped, cancel the micro-deposit immediately.

The question is

  1. As soon as micro-deposit is initiated (meaning the client uses Dwolla’s API to request micro-deposit initiation), is it immediately executed? Or is it queued?
  2. If queued, can the client check on the fingerprint and cancel the microdeposit if a duplicate is detected?
  3. Would removing a funding source cancel the micro-deposits?
  4. If the funding source is removed immediately after checking the fingerprint, would micro-deposit fees still be incurred?
1 Like

Hi @Min_Kang , See my replies below!

Micro-deposits follow the same processing as normal ACH transfers that are created on the Dwolla platform and are batched. They would then go out on an end of the day ACH file.

Are you referring to the funding source fingerprint? This should be returned from the API once a funding source is created.

Yes, removing a funding source should cancel any pending micro-deposits

Same response as above. removing a funding source should cancel pending micro-deposits. Transactional costs related to ACH transactions are only incurred when they are exported.