You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this case we could use the same setup for uploading wire files, ach files, BSA/Compliance files as needed to partners, you could still have different upload agents for each if needed but the generic nature of this need would go a long way.
I feel like otherwise we'll end up duplicating several parts of ach gateway multiple times with various systems when some configuration changes would be everything that is needed, though I understand that would also mean a fairly good size refactor of the codebase possibly.
The text was updated successfully, but these errors were encountered:
I agree that a more generic solution would help with Wires, ICL, generic reports, etc and that's a personal goal of mine.
Converting achgateway into a generic uploader might be more work than I'm willing to signup for. It's working pretty well so far and has some ACH details backed into it. We know that the config is confusing in several spots, so a cleanup there would be nice.
We're talking about a "file collector" internally which is a generic downloader from multiple SFTP endpoints, so a generic uploader would be very similar to that. cc @atonks2 and @alovak
I think achgateway has taught us a lot about building these kinds of uploaders and I'd like to see a real-time uploader/downloader come out of that project. ACHGateway will continue to work and after a config refresh should continue to scale for us. I'm worried about making it generic when we're going to need a few rounds of performance improvements to it in 2023 and beyond. The two problems (real-time vs batch) have different solutions at larger scales.
In this case we could use the same setup for uploading wire files, ach files, BSA/Compliance files as needed to partners, you could still have different upload agents for each if needed but the generic nature of this need would go a long way.
I feel like otherwise we'll end up duplicating several parts of ach gateway multiple times with various systems when some configuration changes would be everything that is needed, though I understand that would also mean a fairly good size refactor of the codebase possibly.
The text was updated successfully, but these errors were encountered: