capture/refund guard lets a ₹0 amount through

Nobody has started this yet — be first.

Business impact

positiveAmountGuard is the one guard standing between "capture"/"refund" and a payment that has no real money attached to it. If it lets amount_minor = 0 through, a captured payment with zero value becomes a valid, terminal-adjacent state in the ledger -- invisible in most revenue dashboards (₹0 doesn't move any totals) but very visible to finance during reconciliation, and a clean way for a data-quality bug elsewhere to slip a "successful" payment into the system that represents no actual transaction.

Problem

positiveAmountGuard only rejects a negative AmountMinor; zero passes.

Current behavior

A capture or refund fired with AmountMinor=0 succeeds instead of being rejected by positiveAmountGuard.

Expected behavior

Zero should be rejected exactly like a negative amount -- the guard's own error, errNonPositiveAmount, literally says "must be positive".

Steps to reproduce

go test ./tickets/tests/... -run TestTicket04 -v

This also collaterally breaks the project's own existing test, TestPaymentMachine_ZeroAmountGuard_RejectsCapture in internal/payment/machine_test.go -- that's expected; both should go green together once this is fixed.

Why this matters

positiveAmountGuard is attached (via internal/payment/machine.go's BuildMachine) to both the capture and refund transitions. Its condition determines what data ever reaches the corresponding Action (which schedules the actual bank-facing outbox call) -- so this boundary is the last line of defense before a zero-value capture/refund is treated as legitimate.

Suggested approach

The fix is entirely inside positiveAmountGuard in internal/payment/machine.go -- a single comparison operator, the same class of fix as ticket 01. Don't touch the transition table itself.

Acceptance criteria

positiveAmountGuard rejects AmountMinor == 0.
positiveAmountGuard still rejects AmountMinor < 0.
positiveAmountGuard still allows AmountMinor > 0.
tickets/tests/ticket04_test.go passes.
The project's own TestPaymentMachine_ZeroAmountGuard_RejectsCapture (in internal/payment/machine_test.go) passes again.

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket04 -v && TEST_DATABASE_URL=postgresql://... go test ./internal/payment/... -run TestPaymentMachine_ZeroAmountGuard -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/zero-amount-guard-boundary

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/zero-amount-guard-boundary

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Paystate — Declarative Payment State Machine

A production-grade declarative state-machine engine, demonstrated by a realistic payment lifecycle -- durable per-state timeouts and crash-recovery via a transactional outbox are the central engineering problems, not an afterthought.

Fork on GitHub

Download

Setup

Paystate — Declarative Payment State Machine

git clone <your-fork>
cd GolangDevTraining/paystate
docker compose up --build   # postgres + 2 app replicas + adminer

's build context is the repository root (one level above ), not itself -- has a local , reusing that sibling project's jittered-backoff package directly. Run from inside as usual; Compose resolves relative to the compose file regardless of your shell's working directory. shortens / to 10s/20s so the auto-expiry demo finishes fast.