Based on Dwolla-generated IDs, such as transfer_id and correlation_id, what is the best recommendation for setting up data table for revenue reconciliation purposes? What IDs are constants and what are variable?
1 Like
Hi @khastie,
There are different Transfer IDs for each leg of the transfer. Once set, they never change. Once you set a correlation Id on a transfer, the same value is propagated onto subsequent legs of the transfer.
As for a recommendation for setting up data table for revenue reconciliation purposes, other users of Dwolla may weigh in on how they have this set up, but In the meantime, I let our AI chatbot from the docs take a crack at it. Here’s what it came up with (which I have reviewed for accuracy regarding Dwolla’s transfer IDs and correlation IDs):
For revenue reconciliation using Dwolla, it’s important to understand the roles of Dwolla-generated IDs:
Key IDs
transfer_id: This is a unique identifier generated by Dwolla for each individual transfer resource. In a multi-leg transfer (e.g., bank-to-bank between two customers), each leg will have its own unique transfer_id. These are variable—each transfer event (or leg) gets a new transfer_id, even if they are part of the same overall payment flow.
correlation_id: This is a string you (the client) provide when creating a transfer. It is attached to all related transfer resources for that payment flow. The correlation_id is constant across all legs of a single logical payment, allowing you to group and track all related transfers together for reconciliation. You can use any unique string (e.g., invoice number, order ID, UUID), but it should not contain PII. The correlation_id is included in both the transfer resource and in webhook payloads for transfer-related events, making it ideal for reconciliation and tracking in your database Using Correlation IDs to Streamline Your Transfer and Webhook Processing, Transfer Lifecycle: Correlation ID.
Best Practice for Data Table Design
Store each transfer as a separate row, using the Dwolla-generated transfer_id as the primary key.
Include the correlation_id as a column. This allows you to group all related transfers (legs) for a single payment flow.
Track other relevant fields such as status, amount, created timestamp, customer_id, and any metadata you need for reconciliation.
Use the correlation_id for reconciliation: When reconciling revenue, query your table by correlation_id to see all transfer legs associated with a single business transaction, regardless of how many transfer_ids are involved.
Example Table Schema
transfer_id (PK) correlation_id status amount created_at customer_id … 74c9129b-d14a… 8a2cdc8d-… processed 10.00 2018-11-29T21:00:59Z 33e56307… … … 8a2cdc8d-… pending 10.00 … … … Summary
transfer_id: Unique and variable per transfer leg.
correlation_id: Constant across all related transfer legs for a single business transaction—use this for grouping and reconciliation.
This approach ensures you can efficiently reconcile revenue by grouping all related transfers using the correlation_id, while still tracking each individual transfer event with its unique transfer_id Transfer Lifecycle: Correlation ID, Using Correlation IDs to Streamline Your Transfer and Webhook Processing.
Hope this is helpful! Happy to answer any follow up questions!
Thank you for clarifying, Shreya! Very much appreciated.
1 Like
This topic was automatically closed after 365 days. New replies are no longer allowed.