Build payments-api REST layer (Layer 3), mirroring customers-api

6 routes over Payment, composite key (customernumber + checknumber),
proxying to classic-models-api. openid-connect with RFC 8693 token
exchange to classic-models-api audience, rate-limiting, proxy-cache,
audit-log — same structure as customers-api's REST layer.

Keycloak (local): payments-api-audience client scope + payments-api
resource client added, attached to kong-token-exchange-broker's
default scopes. No dedicated protocol mappers on payments-api
itself, same practice as customers-api/mcp-customers.

No MCP layer — same as customers-api, not needed yet.

README.md

@@ -1,12 +1,52 @@
 # payments-api
 
-Placeholder component repo for the **payments** slice of
-`classic-models-api` (see /Users/stephanetailland/git/classic-models-api),
-split out per the DDD decomposition documented in
-`../kong-konnect-deployment-strategy.md`.
+Kong routing/policy layer for the **payments** slice of
+`classic-models-api` (see `/Users/stephanetailland/git/classic-models-api`),
+split out per the DDD decomposition in `../kong-konnect-deployment-strategy.md`.
+The backend itself stays a single monolith — only Kong does the domain
+split. Structure mirrors `../customers-api`, not `../catalog-api` — see
+`../STATUS.md` section 18 for why (`catalog-api`'s two-route MCP pattern
+has a latent bug; `customers-api`'s single-route pattern is the corrected
+one to copy going forward).
 
-This repo does not yet contain migrated application code — only the
-routing scaffold (layer 3: `HTTPRoute`/`KongPlugin`/`KongConsumer`,
-alongside the eventual app manifests), targeting the Control Plane(s)
-provisioned for `payments` (see `../konnect-platform/domains/payments/`
-and `../dataplane-payments`).
+**REST only, no MCP layer.** 6 routes over `Payment`, which uses a
+**composite key** (`customernumber` + `checknumber`, not a single id like
+`Customer`/`Product`) — both URI segments are captured and passed through
+to the backend's own composite-key URL pattern.
+
+| Route | Method | Backend path |
+|---|---|---|
+| `/payments/v1/payments/` | GET, POST | `/classic-models/api/v1/payments/` |
+| `/payments/v1/payments/{customernumber}/{checknumber}/` | GET, PUT, PATCH, DELETE | `/classic-models/api/v1/payments/{customernumber}/{checknumber}/` |
+
+## Auth
+
+`openid-connect`, `audience_required`/token-exchange target =
+`classic-models-api` (`BACKEND_AUDIENCE`) — same second-hop-exchange
+pattern as `customers-api`'s REST layer: a caller gets a
+`payments-api`-audience token from `kong-token-exchange-broker` directly
+(no MCP hop exists for this domain), and this layer exchanges it again to
+`classic-models-api` before the backend ever sees it. IdP is the local
+Keycloak (`https://keycloak.sttlab.local/realms/classic-models`) — see
+`../STATUS.md` sections 15/16. **No `payments-api` Keycloak client or
+`payments-api-audience` client scope exists yet** — unlike `customers-api`,
+this hasn't been created on the local Keycloak (nor attached to
+`kong-token-exchange-broker`'s default scopes) as of this repo's initial
+build. Nothing can actually authenticate against these routes until that's
+done — same missing piece as `customers-api` had before its own Keycloak
+wiring step.
+
+## Other policies
+
+Per-consumer rate limiting, response caching (GET/HEAD), audit log
+(`http-log`, endpoint still a placeholder — no real log collector in this
+lab, same caveat as the other domains).
+
+## Structure
+
+Same `dev/` + `kong/rest/` layout as `customers-api`. Deploy key
+(`kong-v2/payments-api/git-deploy-key`) is a **copy of `catalog-api`'s**,
+not a freshly generated one — per the user's explicit instruction this
+session ("no reason a working key for catalog-api wouldn't work for
+customers-api"), the same reused key is used here too rather than minting
+yet another one per domain.