Looking for contributors: Can we make payment infrastructure more resilient with Rust?

Sujith Putta — Fri, 16 Oct 2026 05:33:24 +0000

What happens when a payment gateway is healthy, but the bank rail it depends on starts failing?

Simply adding more application instances may not solve a downstream failure. It can even increase pressure on an already degraded dependency.

I've been building Esapay, an open-source experimental project exploring this problem through multi-signal failure diagnosis, AI-assisted remediation proposals, and deterministic Rust safety checks.

The project includes a Rust backend, TypeScript and Python SDKs, a CLI, a dashboard, and simulated payment-rail failure scenarios.

Now I want other developers to help me find out what actually works, what breaks, and what needs to improve.

I'm looking for honest technical feedback, including criticism. In particular, I'd love help with:

Verify whether it actually works: Clone the repository, follow the setup instructions, run the available tests, and check whether the documented features behave as expected. Report anything that fails or cannot be reproduced.

Improve the SDKs: Test the TypeScript and Python SDKs, identify API inconsistencies, improve error handling, and suggest better developer experience.

Strengthen the CLI: Test the commands, validate their outputs, identify confusing behaviour, and suggest useful missing functionality.

Challenge the resilience logic: Test degraded payment rails, timeouts, intermittent failures, failover decisions, and unexpected edge cases.

Review the AI and safety architecture: Check whether proposed recovery actions are properly validated and whether the safety boundaries hold under failure conditions.

Improve testing and documentation: Add reproducible tests, clarify setup instructions, and help verify benchmark methodology and results.

You don't need to understand the entire codebase to contribute. A reproducible bug report, an SDK improvement, a better CLI command, a failed setup step, or a thoughtful architecture review would all be valuable.

Where you can start

13 — Verify the development setup

14 — Improve payment-rail failure-injection scenarios

15 — Improve safe SDK timeout handling

Repository: https://github.com/sujithputta02/Esapay

Demo: https://youtu.be/77qjP2yK7Og

Good First Issue listing: https://goodfirstissue.org/sujithputta02

One important clarification: the published benchmarks use simulated workloads. Esapay is an experimental resilience project, not a production payment processor. I want independent developers to help verify its current behaviour rather than assume every feature or performance claim is already proven.

If you try Esapay, I'd love to know: Does it work as documented? What fails? What would you improve first in the architecture, SDKs, CLI, or testing?

Honest criticism and reproducible issues are just as welcome as pull requests. Let's make it better together.

DEV Community: Sujith Putta

Looking for contributors: Can we make payment infrastructure more resilient with Rust?

13 — Verify the development setup

14 — Improve payment-rail failure-injection scenarios

15 — Improve safe SDK timeout handling