⭐ Payment Service

payment-service charges on order creation and compensates (refunds) on restaurant rejection — Kafka-driven only, no HTTP controller. Topics, port, and schema are on the services-reference.html diagram; the compensation mechanics themselves are on saga-flow.html.

Checking the actual saga dependency graph (not assumed from module build order) showed payment-service, not restaurant-service, is the real next link after order-service — it consumes OrderCreatedEvent and produces the event restaurant-service itself depends on.

handleOrderCompensation — reacting to restaurant-rejected-topic — is the concrete example of the pattern this whole repo demonstrates: undoing a charge already committed, because a later saga step failed. See Saga Flow for how it fits with order-service's own reaction to the same event.

payment-service's code-review audit is complete — 14/14 files, 4 real findings fixed, 0 findings left open: a payment-decline path that never existed (PaymentStatus.FAILED was dead code — a payment could never actually fail), a refund compensation that never checked whose order it was refunding, a test-coverage gap on two idempotency-guard queries, and an unbounded Kafka-send timeout. See docs/code-review.md for the full write-up.