Creating a ₹0 payment returns 500 instead of 422

Nobody has started this yet — be first.

Business impact

Any client (a checkout page with a broken discount calculation, a batch import script with a bad row) that ever sends amount_minor: 0 gets back a 500 Internal Server Error. Most HTTP clients and retry middleware treat 5xx as "transient, safe to retry" and 4xx as "your request is wrong, fix it and don't retry blindly" -- so this single boundary bug turns one bad request into a retry storm against an endpoint that will never succeed for that payload, and it pollutes server-error-rate dashboards/alerts with noise that isn't actually a server problem. Anyone on call investigating an "error rate spike" alert will burn time confirming it's just a client sending zero-amount requests.

Problem

POST /v1/payments with {"amount_minor": 0, "currency": "INR"} returns 500 Internal Server Error with body {"error":"payment: amount_minor must be positive"}.

Current behavior

A zero-amount payment creation request returns HTTP 500 with the payment-service's own validation error message, instead of a clean 422.

Expected behavior

The same request should return 422 Unprocessable Entity with a body like {"error":"amount_minor must be positive"} -- a clean, actionable client error, not a fault that looks like our server broke.

Steps to reproduce

go run ./cmd/paystate # or use the ticket test below, no server needed curl -i -X POST localhost:8080/v1/payments
-H 'Content-Type: application/json'
-d '{"amount_minor": 0, "currency": "INR"}'

-> HTTP/1.1 500 Internal Server Error

Why this matters

createPayment has its own early boundary check meant to reject non-positive amounts before ever calling payment.Service.Create. If that check's boundary is off, a request slips through to Service.Create, which has its own, separate amount validation (errNonPositiveAmount in internal/payment/machine.go) and returns a plain Go error. createPayment's generic if err != nil { ... StatusInternalServerError ... } branch then maps any Service.Create error -- including this one -- to 500. Two independent validation layers existing is itself fine (defense in depth), but only if their boundaries actually agree; here they don't.

Suggested approach

Look at the comparison operator in createPayment's amount check in internal/api/payments_handler.go, and compare it against what the error message right next to it says the rule is ("must be positive"). Zero is not positive. You do not need to touch writeServiceError or payment.Service.Create -- the fix is a single comparison operator.

Acceptance criteria

POST /v1/payments with amount_minor: 0 returns 422, not 500.
POST /v1/payments with amount_minor: -100 still returns 422 (don't just flip the bug the other direction).
POST /v1/payments with a valid positive amount still returns 201 as before.
tickets/tests/ticket01_test.go passes.

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket01 -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-returns-500

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-returns-500

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.