Lack of detail & wrong transaction detail from Dwolla's accounting records

(CMH) #1

We have our own eCommerce site & are using Dwolla’s off site gateway to process the transactions but have found the transaction ID does NOT match the transaction ID listed in our Dwolla merchant account summary under the Money in. The transaction ID that is returned back to us is the transaction ID that the customer will see in their Dwolla account. It would appear that there are two transaction IDs generated, one that the customer paying for something at our store & one that the merchant sees when some purchases something from our store.

Customer sees transaction ID of xxxxx94, we receive back transaction ID xxxxx94 from the URL call back which we import and include on our invoice.

But when I look at our Dwolla account the transaction ID number is xxxxx93 & there is NO information in the detail section about the transaction orderId or purchaseOrder. The only other place the transaction ID xxxxx93 is transmitted to us is via the email notice that “Money received” again there is no detail provided with this email other than amount, name.

Seems like if there are TWO transaction IDs, then we should receive both transaction IDs in the form of say:
Customer transaction ID: xxxxx94
Merchant transaction ID: xxxxx93

The lack of details & not having the correct info available from the Dwolla account seems like a problem when it comes to reconciling our accounting records with Dwolla’s accounting records

(Gordon Zheng) #2

You’re absolutely correct. Behind the scenes, each payment is actually represented as at least two transactions: a debit from the sender’s account, and a credit to the recipient’s account. Each of these transactions has a unique Transaction ID, and this is why the merchant sees a different ID than the customer sees when looking at the same payment.

Admittedly, this is confusing. We’re aware of the issue and are brainstorming ways to improve this. One idea I’m a fan of is abstracting away the idea of a transaction, and instead assigning a single Payment ID which both parties would see (which is what you’d intuitively expect).

In the mean time, however, there’s a way for you to map each Sender’s transaction ID to the Recipient’s transaction ID. To elaborate, you can call the Transactions / ById endpoint to lookup the transaction ID seen by the sender (which is the same transaction ID returned by the Gateway) in order to get the transaction ID which you, the merchant, would see on your statement and in your dashboard.

For example, I, Gordon, will send money to Brian and get back the following response, which contains my, the sender’s, transaction ID.

    "Success": true,
    "Message": "Success",
    "Response": 4239855

Then, using Brian’s OAuth token, I can lookup the sender’s transaction ID, 4239855, and get Brian’s corresponding transaction ID, which we discover to be 4239854:

    "Success": true,
    "Message": "Success",
    "Response": {
        "Id": 4239854, // <- recipient's transaction ID!
        "Amount": 0.01,
        "Date": "12/13/2013 16:00:57",
        "Type": "money_received",
        "UserType": "Dwolla",
        "DestinationId": "812-552-5953",
        "DestinationName": "Brian",
        "SourceId": "812-687-7049",
        "SourceName": "Gordon Zheng",
        "ClearingDate": "",
        "Status": "processed",
        "Notes": "",
        "Fees": null

Now, back to your situation, you can fetch your transaction ID after each successful Gateway payment and store it, so that later you’ll be able to reconcile your accounting records.

To generate an OAuth token for your merchant account, use our Token Generator.

Let me know if I can better clarify any of this!

(CMH) #3

I created a Token within my merchant account but when I do a query I get back “{“Success”:false,“Message”:“Invalid access token.”,“Response”:null}”. It does not matter which transaction ID I use.

But in your example above you mention “Then, using Brian’s OAuth token” how do I get the other parties OAuth token? Or was that not what you meant?

I am confused.

(Gordon Zheng) #4

Hm. Are you url-encoding the token in your request?

If you append the token directly at the end of the URL you’ll get that error since the token most likely has special characters which need to be escaped (like “/” or “+”).

You can encode your token using Javascript (right from your browser’s developer console!) like so:

encodeURIComponent("your token here")

Which would give you something like


Then make the request as usual:{transactionID}?oauth_token={encoded_oauth_token}

(CMH) #5

That was the problem, thank you for your help.

I agree a single unique Payment ID would be less confusing for all parties.

(Go Daddy Inc) #6

Is it possible for you to put in a quick fix, where you send the merchant transaction ID in customer’s transaction and vice versa? Mapping the IDs by retrieving each transaction’s details seems a little inefficient.

(Karin Powell) #7

It is now 2017 and I found there are two “transaction” numbers: transaction and destinationTransaction

? signature=[the signature]
& orderId=nnnn
& amount=[amount in currency format without symbol]
& checkoutId= [ a really long string ]
& status=Completed
& clearingDate = 2017-02-01T19:49:27.080Z
& transaction= [ very long numeric value ]
& destinationTransaction= [ very long numeric value ]
& postback=success

I have verified myself:

  • destinationTransaction is a numeric value that equals the Transaction ID displayed on the recipient’s screen in association with the transaction AND in the auto-generated emails SENT TO the recipient which are coming from Dwolla regarding the transaction.

  • transaction is a numeric value that equals the Transaction ID that is displayed on the sender’s Dwolla screen in association with the transaction AND in the auto-generated emails SENT TO the sender of the money which are coming from Dwolla regarding the transaction.

In other words: Sender always sees “transaction” value as the transaction ID and Recipient always sees “destinationTransaction” as the transaction ID.

(Spencer Hunter) #8

@KarinDPowell, You are correct in that the Offsite Gateway’s redirect will return the transaction which is the senders transaction id as well as the destinationTransaction which represents the recipients transaction. The use of multiple transaction ids was improved to a single transfer id in our latest v2 API.

Reference our v1 docs for more information on how transactions work in our legacy API: