Skip to content

8.4 Payment Service - Scaffold and Schema

Sprint: Sprint 08 - Order and Payment
Feature ID: 8.4
Subtasks: 8.4.1, 8.4.2

Objective

Deliver "Payment Service - Scaffold and Schema" within Sprint 08 - Order and Payment.

Dependencies

Aggregated from the subtasks below (prerequisite task IDs and enablers):

  • 3.4.1
  • Sprint 04
  • 8.4.1

Subtasks

8.4.1 Scaffold payment-service from template

  • ID: 8.4.1
  • Title: Create payment-service from the service template
  • Description: Instantiate microservices/payment-service (port 9008, base package com.telco.payment) from the template; depend on starter-api, starter-security, starter-mediator, starter-observability, starter-outbox, starter-inbox; own the payment database; audit logging enabled. Architecture mode: Domain Orchestration (ADR-004) - charge/retry/refund workflow coordinating the PSP and saga events; declare it in CLAUDE.md/README.
  • Business Purpose: Standardized payment-domain service skeleton.
  • Inputs: ADR-017.
  • Outputs: payment-service skeleton building and registering.
  • Acceptance Criteria:
  • Service starts, registers, exposes Swagger UI.
  • Dependencies: 3.4.1, Sprint 04
  • Complexity: S

8.4.2 Payment schema migration

  • ID: 8.4.2
  • Title: Create Flyway migration for payments, attempts, idempotency
  • Description: V1__payment.sql creating payments (id, invoice_id nullable, order_id nullable, amount, currency, method, status, external_ref, payment_request_id unique, paid_at), payment_attempts (id, payment_id, attempt_no, response, attempted_at), and an audit table. The unique payment_request_id enforces idempotency (FR-26).
  • Business Purpose: Persist payments and attempts with idempotency (FR-26).
  • Inputs: analysis Section 10.7, FR-26.
  • Outputs: Flyway migration.
  • Acceptance Criteria:
  • Migration applies; a duplicate payment_request_id insert is rejected by the unique constraint.
  • Dependencies: 8.4.1
  • Complexity: M

Acceptance Criteria

Each subtask above carries its own objective, testable acceptance criteria. This feature is complete when every subtask's acceptance criteria are met.

Deliverables

  • payment-service skeleton building and registering.
  • Flyway migration.

Definition of Done

  • All subtasks (8.4.1, 8.4.2) completed and their acceptance criteria verified.
  • All listed dependencies satisfied.
  • Build and tests green per the global conventions in ../README.md (Section 3).