Hello! We send the same Addenda information for debits and credits, but they only appear on transactions that are credits? For example, a transaction id: 9650d928-7a6f-ef11-ac7e-0a27ad48efdb on 9/10 from our bank account to a customers account, has no addenda info. Yet, A credit transaction from our customer to us, having transaction id: af4a0e6f-736f-ef11-ac7e-0a27ad48efdb on 9/10, does contain Addenda information. Both credit and debits in the API use the same function, which assign the source and destination addenda keys. Any assistance would be greatly appreciated. Thank you.
Hi @James_Whitfield , I looked at our API request logs and it appears that the achDetails and addenda object aren’t in the raw request body for the transfer 9650d928-7a6f-ef11-ac7e-0a27ad48efdb. Is there something different on your end with how these transfer requests are created that could be the cause of the issue?
Thank you so much @spencer for your quick assistance! Hmmmm… can you confirm the credit with transaction id: f4a0e6f-736f-ef11-ac7e-0a27ad48efdb does contain addenda data? If so, that is the same transfer function used for debits… and as a result, was trying to understand in what scenarios it wouldn’t be included. I understood addenda data is always supported by various banks, but given we did receive it for credits I’m a little perplexed. Thank you
Hi @James_Whitfield, Unfortunately I’m not able to find the request body for that transfer in our API request logs. I am seeing that the addenda was successfully sent on the ACH debit, however, I won’t be able to confirm on the ACH credit until tomorrow.
Thank you so much @spencer! That is very helpful. Also, if it makes your job easier. Our latest credit transaction with addenda info is c22db280-1c71-ef11-ac7e-0a27ad48efdb. And our debit latest transaction without addenda info is d4bce805-1971-ef11-ac7e-0a27ad48efdb , both from 9/12. Thank you!
1 Like
Hey @spencer ! Just following up regarding your confirmation of both transactions. Thank you.
Hi @James_Whitfield,
I am seeing that the API request for the credit transaction c22db280-1c71-ef11-ac7e-0a27ad48efdb has an “achDetails” object in the request body along with “metadata” and “correlationId”.
The debit transaction d4bce805-1971-ef11-ac7e-0a27ad48efdb on the other hand doesn’t have those objects in the API request body. It just has the source and destination links along with the amount.
It appears there might be some kind of a pre-request job in your application that is adding achDetails, metadata and correlationId to credit transactions and not to debit transactions.
Hope that helps! Let us know if there’s any other information we can look up on our end to help with your investigation!
Thank you very much @shreya !!! This will go a long way to debugging. Is it possible to get the raw payload you saw for both? If not offline, the personal values can be scraped (XXXXX). Basically, as mentioned… the debit & credit is same_function(a,b) or same_function(b,a) (notice a/b swapped) . As you can see, the reason I would be perplexed and thought of it may be outside our app, but could be wrong. The payloads help in seeing if it was transformed in any way. In the meantime, I will consider other alternatives. Thank you!!!
Hi @James_Whitfield, while working on pulling the raw request body, I noticed something that might be the root cause.
The credit requests (transfer ids: c22db280-1c71-ef11-ac7e-0a27ad48efdb, af4a0e6f-736f-ef11-ac7e-0a27ad48efdb) are coming from your Ruby app, so they have the addenda object attached, as expected.
The debit requests (transfer ids: d4bce805-1971-ef11-ac7e-0a27ad48efdb, 9650d928-7a6f-ef11-ac7e-0a27ad48efdb) on the other hand are coming from the Dwolla Dashboard, which doesn’t provide the option to add extra details like addenda, correlationId, metadata, etc. If the debit request was coming from your Ruby app, then it would probably have the related addenda and metadata objects as expected, with no change required to your code.
To help with your investigation further, the debit request was created in the dashboard by sub-user ID 6ac5ab9a-0e26-4a46-a21a-008a5b3e11ee.
Hope this helps! Sorry for not catching that sooner!
2 Likes
Thank so much @shreya ! That was very helpful and exactly what I needed. We have confirmed it is working now 
Have a great day!
1 Like
Glad we got it figured out! Again, sorry for not catching it sooner! 