{
  "reviewRevision": "2026-09-15.5",
  "reviewedAt": "2026-09-15",
  "newPaymentTestsPerformed": false,
  "items": [
    {
      "id": "error-catalog",
      "title": "Error catalog structure",
      "lastEvidence": "Manager review 15 Sep 2026",
      "observation": "Reference lists each scenario once. errors.json and the combined dictionary use businessErrors formatVersion 2 with one items list and ID-only groups. Known wire variants and HTTP scope are retained.",
      "nextStep": "Update parsers of the previous nested error dictionary. No new API error behavior or payment test is claimed."
    },
    {
      "id": "deposit-history",
      "title": "Deposit status history and currency",
      "lastEvidence": "Owner-confirmed 11 Sep 2026",
      "observation": "Both deposit lookups require non-empty orderHistory. Success/Failed wire examples include currency; exact history codes and offset-less UTC times are preserved. Earlier empty H2C history observations are historical, not the approved rule.",
      "nextStep": "Retest the deposit status contract with assigned keys separately; confirm universal currency presence before making that field required. Payout and callback rules are unchanged."
    },
    {
      "id": "create-payloads",
      "title": "Common unsuccessful-create payloads",
      "lastEvidence": "Owner examples · 10 Sep; scope and HTTP confirmed 15 Sep 2026",
      "observation": "Five common response-body examples are available beside every deposit flow. Payout has those five plus Insufficient balance, which applies only to payouts. Reference and Downloads use the same scope. This is not an exhaustive error catalog. Empty-body authentication responses remain in the HTTP guidance.",
      "nextStep": "HTTP is shown beside each payload: created Failed 200, routing 423, payout-only insufficient balance 422, limit/duplicate/required-field errors 400. CreatedFailedResponse is a separate HTTP200 schema branch; existing successful-response requirements are preserved. HTTP200 is not payment success. These are owner-confirmed mappings, not new live tests."
    },
    {
      "id": "p2p-state",
      "title": "P2P correction after Failed",
      "lastEvidence": "Owner-confirmed · 10 Sep 2026",
      "observation": "The same P2P order can change Failed to Success, usually after initiation by merchant support. The merchant must handle the corresponding callback update; a reverse Success-to-Failed business transition need not be implemented.",
      "nextStep": "Do not discard a changed status solely because its order ID was seen. Apply updates idempotently. No live correction/callback delivery was tested; correction deadline, eligible reasons and transport/polling details remain to be agreed."
    },
    {
      "id": "p2p-details",
      "title": "P2P alternative payment-detail mapping",
      "lastEvidence": "Owner-provided examples · 10 Sep 2026",
      "observation": "Recipient phone maps to paymentDetails.number; IBAN maps to paymentDetails.iban; account number maps to paymentDetails.accountNumber. QR content is in paymentDetails.qrUrl and can coexist with accountNumber. method ArsCbu is an example, not a discriminator. No new live test was run.",
      "nextStep": "Recipient phone maps to paymentDetails.number (owner-confirmed). Alternative-field nullability/absence rules, method catalog and exact QR encoding remain pending. See Deposits → Payment details fields; new OpenAPI properties are annotations without new value constraints."
    },
    {
      "id": "ecom",
      "title": "ECOM H2H contract and sandbox validation",
      "lastEvidence": "7 Sep 2026",
      "observation": "Owner-provided ECOM H2H/H2C request/response examples are now published. H2H uses paymentDetails.formUrl plus flowData; H2C uses root formUrl. The older saved order reached Success, but full schemas, redirect precedence and validation parity remain unconfirmed.",
      "nextStep": "Confirm the profile-specific contract and use a valid test fixture; a successful sandbox status does not establish customer completion of 3DS."
    },
    {
      "id": "h2c",
      "title": "H2C happy path and hosts",
      "lastEvidence": "7 Sep 2026",
      "observation": "The owner supplied an ECOM H2C example with AZN, PayeerIdentifier and an Init/root-formUrl response. Earlier supplied H2C labels returned missing-FirstName 400. These profile-specific examples do not establish universal required fields or complete live onboarding.",
      "nextStep": "Confirm required fields and routing markers per profile; verify create, form handoff and both status lookups. Do not make firstName universal."
    },
    {
      "id": "payout",
      "title": "Payout access and 422 mapping",
      "lastEvidence": "7 Sep / 24 Aug evidence; scope confirmed 15 Sep 2026",
      "observation": "The latest payout status access check returned an empty 403; the cause is unresolved. An older payout test returned 422 with 1-4010 / 1.1.4.3, identified by the owner as insufficient balance. This error applies only to payouts.",
      "nextStep": "Confirm test-mode payout access before further probes; the body examples do not establish complete live coverage."
    },
    {
      "id": "notifications",
      "title": "Callbacks and operational Events",
      "lastEvidence": "No complete live delivery fixture",
      "observation": "Legacy guidance contains conflicting callback ACK descriptions; signature, retry behavior and current alert support lack dedicated verified fixtures.",
      "nextStep": "Confirm the contract, signed values, secrets, ACK and retries; test delivery and duplicates before production."
    },
    {
      "id": "timestamp",
      "title": "History timestamp serialization",
      "lastEvidence": "UTC confirmed 8 Sep 2026; offset-less status wire observed 8 Sep 2026",
      "observation": "The owner confirmed that orderHistory[].time in deposit and payout status responses is UTC. Interpret an offset-less value as UTC, not local time. The schema still declares date-time, and the missing suffix remains a serialization discrepancy.",
      "nextStep": "Retain UTC semantics and agree a compatible explicit timezone suffix in the API response. Do not relax the schema or apply this rule to callbacks or Events createdAt."
    },
    {
      "id": "auth",
      "title": "Status authentication responses",
      "lastEvidence": "25 Aug 2026",
      "observation": "Twelve missing/invalid/Bearer-scheme cases across four status operations returned empty 500 responses rather than the expected 401.",
      "nextStep": "Retest and fix auth handling before order lookup; a valid wrong-capability key needs a separate approved control."
    },
    {
      "id": "currency",
      "title": "Deposit unknown currency versus routing",
      "lastEvidence": "Owner decision 9 Sep 2026; H2H routing evidence 8 Sep 2026",
      "observation": "CUR-002 confirms 423 for the discussed unrecognized RU and ZZZ values in Deposit H2H/H2C, with statusDescrption 2-00100-2 and code 1.2.4.9. The approved message template is Currency value \"{currencyKey}\" is unknown; that refined message is not yet live-verified. A separate H2H EUR case returned 423 / 0000-2 / 1.2.4.3.",
      "nextStep": "CUR-CRYPTO-001 (10 Sep 2026) removes the inferred alpha-3 format check: currency is a string key. Payment creation first looks up the currency in the internal dictionary, then finds a route by pipeline conditions. USDT_TRC20 is an illustrative input, not a guarantee of enabled support. RU and ZZZ are unknown-currency evidence, not independent routing coverage. CREATE-HTTP-001 confirms HTTP423 for the common no-matching-route response (15 Sep 2026). Profile support and live coverage remain separate open points."
    },
    {
      "id": "fields",
      "title": "Additional-field and URL validation",
      "lastEvidence": "23–24 Aug 2026",
      "observation": "Malformed additionalFields produced 500 in historical tests; a missing value and malformed URLs were accepted in some cases.",
      "nextStep": "Confirm URL policy and retest field validation. Accepted negative cases must be journaled and followed by status."
    },
    {
      "id": "balance",
      "title": "Balance validation fixed; lowercase and no-balance policy pending",
      "lastEvidence": "9 Sep 2026 · secure.paystar.uk",
      "observation": "A read-only retest with one confirmed test profile returned 400 BusinessError for missing, empty and RU currency, 200 Balance for both RUB controls, and 401 for missing/invalid authorization. Seven HTTP expectations and seven JSON schemas matched. rub and ZZZ changed from 204 to 400 and remain separate configuration observations.",
      "nextStep": "Treat missing/empty/RU as fixed for this tested profile and host. Confirm lowercase and no-balance policy before changing the Balance contract. Deposit 423 handling does not apply here."
    },
    {
      "id": "token",
      "title": "Tokenized flow and sensitive response fields",
      "lastEvidence": "Dedicated onboarding pending",
      "observation": "No dedicated tokenized happy path or current callback fixture is available. cardMask semantics/nullability remain unconfirmed.",
      "nextStep": "Confirm token issuance, reuse and customer steps; agree response fields without inferring a closed schema from one sample."
    }
  ]
}