Testing MonCash and NatCash flows in CI without calling the real APIs
asked 2 months ago166 viewsen
Our CI pipeline can't use real MonCash credentials, and NatCash has no public sandbox. How do we still get confidence that payment code works before deploying?
AI diagnosis
AI-generated. Not an answer — the community below confirms or corrects it. Always verify before relying on it.
1 Answer
Test at three levels, and use the real APIs only at the top:
1. Unit tests with a fake provider (every commit)
Your checkout logic depends on the PaymentProvider interface, so a fake implementation covers most of it:
class FakeProvider implements PaymentProvider {
readonly id = "MONCASH" as const;
next: Awaited<ReturnType<PaymentProvider["status"]>> = { status: "SUCCEEDED", amountHtgCents: 125000 };
async start() { return { kind: "redirect" as const, url: "https://fake/pay" }; }
async status() { return this.next; }
}
it("does not mark paid when the amount differs", async () => {
fake.next = { status: "SUCCEEDED", amountHtgCents: 500 };
expect(await confirmAttempt(attempt.id)).toBe("FAILED");
});
Cover the nasty cases: amount mismatch, duplicate confirmation, provider timeout, 401 then retry, and a payment arriving after expiry.
2. HTTP-level tests of each client (every commit) Mock the network layer (e.g. msw for Node) with recorded, anonymized responses from the real API. This catches wrong headers, form versus JSON bodies, and parsing mistakes, without credentials.
3. Real sandbox or small live test (before release, not every commit) A manual or scheduled job with sandbox credentials stored as protected CI secrets, or a tiny real transaction for providers with no sandbox. Keep it out of pull-request builds so forks can't read the secrets.
When a real response ever surprises you in production, add it to the recorded fixtures. The test suite then gets more realistic over time.
Sign in to tell others whether this worked.
Sign in and verify your email to post an answer.