3

I think that the Dwolla API sends the wrong transaction ID in notifications. In a normal dwolla money transaction, two transaction IDs are created (this is weird to me, but that's how dwolla does it). Because these two are created at the same time, they are always (in my experience) consecutive numbers. So e.g. if account X sends money to account Y, Y will see transaction id M, and X will see transaction id M+1.

But Dwolla's notification webhook will send Y details of the transaction with id M+1. While ID M+1 is still unique to this transaction, ID M+1 cannot be used by Y via the API - because M+1 is supposed to only be used by X.

Here is a specific example:

  1. Via my webapp, I send money from my personal dwolla account to my organization's via the off-site gateway api.

  2. My webapp is sent the transaction details in both callback and notification form. The transaction id generated by step 1 is 1431566. This is the transaction id sent to both callback and notification. My web app stores this Id for future use.

  3. Via my webapp, I decide to refund my personal dwolla account from my organization's so:

  4. My webapp tries to query dwolla about transaction 1431566, to get the SourceId, but this fails - dwolla reports "Transaction not found for account". My automatic refund cannot continue without an ugly kludge like subtracting one from the Id and trying again.

    The manual workaround is to login to my organization's dwolla account via the web interface. Here I can look for the transaction based on datetime and I can see that the transaction ID is actually 1431565 (correctly reported in the web interface). If I go into my organization's database and replace 1431566 with 1431565, I can repeat step 4 and it works this time. After that I can initiate a send() and the refund goes through.

I reported the same problem here before dwolla moved support to stackoverflow: https://getsatisfaction.com/dwolla/topics/callback_and_webhook_notification_sent_wrong_transaction_id_off_by_one

I figure it will be fixed faster if other people have the same problem. Or maybe I'm missing something obvious and someone will point it out.

Community
  • 1
  • 1
chrishiestand
  • 2,800
  • 1
  • 25
  • 25
  • 1
    I am puzzled about this too. I just had a transaction that completed. The transaction Id was reported through the webhook as XXXX132. When I look at the Dwolla site, it had the id XXXX131 and the .25c fee has the id XXXX130. Can somebody please clarify? – gae123 Jan 04 '13 at 00:01
  • The XXXX132 and XXXX131 are representative of the problem reported here. When Dwolla takes a fee it is counted as an entirely separate transaction, which explains the XXXX130. – chrishiestand Jan 04 '13 at 08:12
  • 1
    As stated in this question: http://stackoverflow.com/questions/14163351/dwolla-transaction-ids-relationship/14167688#comment19631907_14167688, a ticket was entered to return a list of all transaction ids for a particular transfer. – rocky Jan 07 '13 at 17:43
  • @Rocky, I hope that the webhook is also fixed to send the correct transaction ID. However, as long as the correct one could be retrieved it would be a sufficient workaround. – chrishiestand Jan 07 '13 at 23:10

2 Answers2

1

Thanks to Michael's help, we were able to get around this issue by using the receiver's OAuth token when getting the transaction details instead of the sender's OAuth token.

For example, say I send some money using the API and transactions 1202 for the money sender and 1201 for the money receiver get created. If you make the API call to get details for transaction 1202 but use the receiver's OAuth token, it will give you details for transaction 1201, including fee information.

I'm not sure if the situation is exactly the same since we are acting as the facilitator between two transactions, so no guarantees that this will work in your situation. But it's worth a try.

Shea Daniels
  • 3,232
  • 3
  • 23
  • 27
  • Thanks for the attempt at helping. This may be a result of the workaround @Rocky reported in the comments of this question. I will have to test it out and try. It would have been nice if Dwolla had acknowledged this problem, instead I've gotten the cold shoulder for 10 months. – chrishiestand Jul 02 '13 at 21:27
  • No problem. I would have been upset too if there was no way to get this info. I was expecting a unique transaction ID that identifies the whole shebang. Hopefully they can get all the kinks worked out at some point. – Shea Daniels Jul 03 '13 at 16:06
  • This workaround is confirmed, thanks @Shea. I should say that in addition to using the **receiver's** OAuth token, you can also auth with the **receiver's** api key and secret to get the correct transaction id. It depends on the api library. So this really confirms it. The Dwolla webhook sends the incorrect transaction ID. But the transactions/$id api call returns the correct id, even when given webhook's incorrect transaction id. With the help of this workaround I finally have dwolla transactions fully automated. I still wish Dwolla would fix the problem, but this will have to do for now. – chrishiestand Oct 10 '13 at 01:28
-1

So, your application's key & secret can access the transaction ID posted to you by passing the transactionById() method your application's client_id and client_secret, as opposed to the oauth_token. Meaning, when you poll for the transaction, instead of querying this URL:

https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x

Query this url, instead:

https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y

Makes sense?

Michael Schonfeld
  • 478
  • 2
  • 5
  • This is a problem no matter what authentication method is used. Please re-read the problem description. The problem is that the Dwolla notification sends the wrong transaction ID. As an aside, you can see I'm using parameter authentication at this pull request: https://github.com/Dwolla/dwolla-php/pull/10 – chrishiestand Nov 01 '12 at 09:38