Out of scope
Out of scope
Section titled “Out of scope”Write-protected. This document is authority, not a worksheet. The deterministic write gate blocks edits to it.
Everything below is excluded from this change. Implementing any of it is a hard fail regardless of how well the rest of the work is done — not because the behaviour is wrong in general, but because it is not this change, and a payment-grade change that quietly grows is the failure mode this lab exists to prevent.
Excluded by the source specification
Section titled “Excluded by the source specification”| Item | Source |
|---|---|
| All Void flows — Void-Auth, Void-Capture, Void-Pay, Void-Refund | Spec 1, “Out of scope” |
| Pre-settlement reversals | Spec 1, “Out of scope” |
| Unsettled transactions | Spec 1, “Out of scope” |
| Non-card refunds | Spec 1, “Out of scope” |
| DCF and settlement data generation — handled downstream, not in this service | Spec 1, “Out of scope” |
| Pre-risk assessment on subsequent refunds — there is none; inventing a risk or fraud call fabricates a dependency | Spec 1, “Out of scope” |
Excessive refund (EXCESSIVE_REFUNDS) — a later phase |
Spec 1, Phase 1.1 |
| Partial refund, scheme-token and device-payment cases — a later phase | Spec 1, Phase 2 |
Outside the lab runtime
Section titled “Outside the lab runtime”Represented in the wider flow, deliberately not implemented here:
- CPC behaviour and ownership beyond the online/offline state supplied at the seam
- Refund injection, LCS API, DCF generation and the settlement lifecycle
- A3RS, BECS, BPSS and surrounding platform components
- ISO 8583 and DE48 mapping, settlement-specific field processing
- Production routing, regional and blue-green topology
- The production CI/CD, integration-environment and release-governance path
- Merchant-privilege enforcement — the source establishes the privileges but does not assign
enforcement to a component in this slice. See
docs/PGS_DECISIONS.mdopen question 12.3.
Nearby code is not authorisation
Section titled “Nearby code is not authorisation”Code adjacent to the refund path may look reusable, may compile, and may appear to be waiting to be finished. Adjacency is not permission. If you believe something out of scope genuinely must change, the correct action is to record it and escalate — not to implement it and mention it afterwards.