Open-source project · Go · Payments
Payment Sandbox
Testing a payment integration means more than checking HTTP status codes.
The problem
A payment may succeed while the HTTP response is lost. A webhook may arrive twice, late or out of order. Two concurrent capture requests may race. These situations are difficult to reproduce with a traditional HTTP mock.
The approach
Payment Sandbox models payment workflows and the asynchronous behaviours around them. Scenarios are deterministic, observable and reproducible, making it possible to test integrations without depending on a real provider.
- lost responses and retries with idempotency keys;
- delayed, duplicated, invalid or out-of-order webhooks;
- concurrent capture and refund races;
- temporarily inconsistent states and deterministic replay.
Architecture choices
The project uses a modular monolith, domain-driven design and targeted hexagonal architecture. The goal is not to distribute the system artificially, but to isolate boundaries that provide real value: domain, persistence, clock, randomness, durable jobs and HTTP delivery.
Project status
The project is public and under active development. Public contracts and the scenario format are not stable yet, and the project is not presented as production-ready software.