我认为dwolla api在通知中发送错误的事务ID。在普通的Dwolla货币交易中，创建了两个事务ID（这对我来说很奇怪，但这就是Dwolla的做法）。因为这两个是同时创建的，所以（根据我的经验）连续数字。所以例如如果帐户x将钱发送到帐户y，则y将看到交易ID M，并且x将看到交易ID M 1。
但是Dwolla的通知Webhook将使用ID M 1发送交易的详细信息。虽然ID M 1仍然是此交易所唯一的，但Y无法通过API使用ID M 1-因为M 1仅由X。
使用。这是一个特定的示例：
通过我的WebApp，我通过现场网关API将资金从我的个人Dwolla帐户发送到我的组织。
我的WebApp以回调和通知表格发送了交易详细信息。步骤1生成的事务ID为1431566。这是发送到回调和通知的事务ID。我的Web应用程序存储此ID以备将来使用。
通过我的WebApp，我决定从组织的So中退还我的个人Dwolla帐户：
我的WebApp试图查询Dwolla有关交易的1431566，以获取SourceID，但这会失败 - Dwolla Reports; quot; quot; quot; quort oferce;我的自动退款就无法继续没有丑陋的kludge，例如从ID中减去一个并重试。
。手动解决方法是通过Web界面登录我组织的Dwolla帐户。在这里，我可以根据DateTime查找交易，并且可以看到事务ID实际上是1431565（在Web界面中正确报告）。如果我进入组织的数据库并用1431565替换1431566，我可以重复步骤4，并且这次可以工作。之后，我可以启动发送（），退款将通过。
我在此处报告了同样的问题，然后Dwolla将支持转移到Stackoverflow：https：//getSatisfaction.com/dwolla/dwolla/topics/callback_and_webhook_notification_sent_sent_sent_wrong_wrong_wrong_transaction_id_id_id_id_off_off_by_by_one
我认为，如果其他人遇到相同的问题，它将更快地固定。也许我错过了一些明显的东西，有人会指出。
感谢Michael的帮助，我们能够通过获取交易详细信息而不是发送者的Oauth Token时使用接收者的 oauth token来解决这个问题。<<<<<<<<<<<<<<<<
例如，假设我使用API和交易1202寄钱，以获取货币发件人，而1201款用于创建货币接收器。如果您进行API调用以获取交易详细信息1202但使用接收器的OAuth代币，它将为您提供交易的详细信息，包括费用信息。
我不确定情况是否完全相同，因为我们在两项交易之间充当协助者，因此不能保证这在您的情况下会起作用。但这值得一试。
因此，您的应用程序的键＆amp;Secret可以通过传递应用程序的client_id和client_secret而不是oauth_token来访问向您发布的事务ID。意思是，当您进行投票进行交易时，而不是查询此URL：
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x
查询此URL，而是：
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y
有意义？