Why we ended up building a Unified Payment Integration Library?
Posted by cargo_run_rust@reddit | programming | View on Reddit | 6 comments
Posted by cargo_run_rust@reddit | programming | View on Reddit | 6 comments
programming-ModTeam@reddit
No content written mostly by an LLM. If you don't want to write it, we don't want to read it.
c10n3x_@reddit
Curious why you chose to make the library transport-agnostic (no HTTP calls inside), did you ever consider bundling a default HTTP client with an escape hatch for overrides? Feels like it adds friction for simple use cases even if it's cleaner architecturally
Worth_Trust_3825@reddit
I disagree. It's always painful trying to replace an integrated "generic" feature in libraries. ex a json deserializer, or an http client/server just because the dev had his favorite library in there or decided to roll his own. My personal pet peeve is JWT libraries rolling their own json deserializer, and http client for jwk fetching, but adding no support to modify the calls.
ScrapEngineer_@reddit
Because it's vibecoded slop
mbecks@reddit
Hyperswitch is not skip
c10n3x_@reddit
I did go through their website and their brand - looks like they know what they are doing.
While it maybe true that they are using AI to generate code or readme (who isn't at this point). I wouldn't dismiss it by saying vibecoded slop.
for all I care, as long as the library is good and solves my problem w/o an issue - I am happy.