payment-service (Provider P1)

A Spring Boot payments API. In the SpecShield demo it plays the provider: it publishes openapi.yaml and is told, before each deploy, whether the change would break any consumer.

Consumers of this service

Consumer	What it uses
checkout-bff	POST /payments, GET /payments/{paymentId} — reads receiptUrl
finance-reporting	GET /payments (list) — never reads receiptUrl

That asymmetry is deliberate: it is what makes "this change breaks only one of them" demonstrable in Scenario 9 of the test plan.

Run it

mvn spring-boot:run          # http://localhost:8081
curl -s localhost:8081/payments \
  -H 'Content-Type: application/json' \
  -d '{"amount":49.99,"currency":"EUR","customerId":"CUST-1"}'

Publish the spec to SpecShield

specshield bdct publish-provider \
  --provider payment-service \
  --spec openapi.yaml \
  --version 1.0.0 \
  --env production

Org key, spec path and environment come from .specshield.yml, so in practice specshield bdct publish-provider --version 1.0.0 is enough.

Key files

File	Why it matters
openapi.yaml	The contract. This is what gets published.
src/.../api/PaymentResponse.java	The Java shape the spec describes. Keep in sync.
.specshield.yml	Per-project CLI defaults.
.github/workflows/specshield-bdct.yml	Publish + deploy gate + governance in CI.