Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No persistent transaction ID to match with OFX, mobile app or NPP transaction IDs #77

Open
wgrant opened this issue Feb 15, 2021 · 2 comments

Comments

@wgrant
Copy link

wgrant commented Feb 15, 2021

The Up API's persistent transaction UUIDs are a fantastic improvement over other banks' APIs. But the API doesn't expose other identifiers that Up sometimes uses for transactions.

The most important one is the FITID in OFX exports from the Android app, which seems to be an institutionally-unique sequential integer. That it is actually unique (as required by the format) is a great benefit over the OFX exports provided by most Australian banks, but it would be lovely if I could correlate transactions incrementally imported from the API with those from month-end OFX exports.

The only ID exposed in the Android app is the "payment ID", though given the lower rate at which it's incrementing I guess normal card etc. transactions might not have one of these at all.

The Android app exposes the initiator-supplied freeform NPP end-to-end ID (as "Reference ID"), but the API doesn't provide this information. Some other institutions also expose the NPP transaction ID, the 35 character string starting with the originating institution's SWIFT ID, a date, and then (at least in Up's case) an incrementing integer, which is useful for correlating even between different people or banks. I gather that there are limits to the NPP metadata that you can expose, but the transaction IDs don't seem to contain any PII and are shown by other banks.

@d11wtq
Copy link
Contributor

d11wtq commented Mar 29, 2021

Yes, I think we probably have some work to do to align IDs across our other exports. Really good point. The UUID would likely be the one that wins out. Would it be a big issue if we made a backward-incompatible change to the OFX export and switched to using the UUID? I wonder if there's any way to do it besides just switching from one to the other 🤔 I guess because the fields are pre-defined you can't really deprecate one and point to another.

In terms of NPP e2e ID and Up's Payment ID, those are not overlooked but we wanted to include payment data as part of a holistic approach to adding all the rich data that comes with payments into the API.

@l1ll1
Copy link

l1ll1 commented Oct 23, 2023

+1 to this old feature request. Actually I'm more interested in the initiator-supplied freeform NPP end-to-end ID (as "Reference ID"), Would love to be able to get this through the API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants