captured_at/settled_at are swapped when reading a payment back

Nobody has started this yet — be first.

Business impact

captured_at and settled_at are exactly the kind of timestamps finance and support pull for "how long did settlement take" reporting and for answering a merchant's "why hasn't my money arrived" ticket. If they're swapped on every single read, every report built on them is silently wrong -- not crashing, not erroring, just quietly showing the wrong timeline for every payment in the system. This is the kind of bug that doesn't get caught until someone cross-checks the API's numbers against the raw database and the two don't match, at which point nobody trusts either.

Problem

After a payment is captured (but not yet settled), GET /v1/payments/{id} -- and any other caller of Store.Get/GetTx -- shows captured_at: null and settled_at: <the actual capture time>.

Current behavior

A payment that has only been captured (not settled) shows a non-null settled_at and a null captured_at when read back.

Expected behavior

captured_at should reflect when the payment was captured; settled_at should be null until it's actually settled.

Steps to reproduce

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket08 -v

Or manually: create a payment, let it auto-authorize, capture it, then GET /v1/payments/{id} and compare captured_at/settled_at against what you'd expect.

Why this matters

scanPayment does one row.Scan(&p.ID, ..., &p.AuthorizedAt, &p.CapturedAt, &p.SettledAt, &p.RefundedAt, ...)-shaped call, and its argument order must exactly match the column order of the SELECT that produced the row -- paymentColumns, declared right above it as a shared string constant. The two lists have drifted out of sync for the middle two columns.

Suggested approach

Put paymentColumns and the Scan(...) argument list from scanPayment side by side and check each position matches, specifically around captured_at/settled_at. This is purely an argument-ordering fix inside scanPayment -- no SQL, no migration, no other function needs to change.

Acceptance criteria

After capture (before settlement), Get/GetTx return a non-nil CapturedAt and a nil SettledAt.
After settlement, both are non-nil, each with the correct timestamp (capture time earlier than settlement time).
tickets/tests/ticket08_test.go passes.

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket08 -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/captured-settled-scan-swap

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/captured-settled-scan-swap

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.