# SettlementOverrideRequestDto

A model the API reference uses in a request or a response. The operation pages link every field typed as this model here.

Request payload for an admin-driven manual settlement-status override. Designed
from day one to carry one or many transaction ids so the same service can serve
the single-transaction detail-page modal and a future grid bulk-action.

## Fields
- `transactionIds` (array<string(uuid)>) required: The transactions to apply the override to. 1 to 200 ids per request. (nullable, max items 200)
- `newStatus` ([SettlementStatus](https://devportal.demo.winkpg.io/docs/api/models/SettlementStatus.md)): The settlement status to switch to. Must be admin-targetable.
  Values:
  - `WaitingForSettlement`: Transaction is waiting to be settled with the processor
  - `SettlementSucceeded`: Settlement completed successfully with the processor
  - `SettlementFailed`: Settlement failed - requires review and retry (rollback)
  - `NotEligible`: Transaction is not eligible for settlement (voided, reversed, or not yet captured)
  - `SettlementInProgress`: Settlement is currently in progress with the processor.
  - `SettlementOnHold`: Settlement is on hold and cannot proceed at the moment.
  - `SettlementRolledBack`: Settlement was rolled back or reversed after a completed attempt. Distinct from SettlementFailed which indicates a transient failure needing retry.
  - `ReversalFailed`: A reversal was attempted but the processor did not confirm that the authorization hold was voided: the contributor saw a non-Ok result code (transport failure, timeout, swallowed exception, malformed response, etc.). Distinct from NotEligible (a confirmed reversal/void) and SettlementFailed (a settlement-time failure). Operations need to confirm the hold state with the processor and reverse manually if required. The transaction's Stage is left at the pre-reversal value; the close-stage history entry is NOT written.
  - `Pending`: The provider owns settlement and reports the outcome on its own schedule, so the transaction belongs to no gateway batch. Used for ACH sales and alternative payments. A background sync moves the transaction on as the provider reports, through any of the ACH in-flight statuses, to a terminal status.
  - `Accepted`: The ACH processor has accepted the transaction for processing. VeriCheck V2 only: the entry has been received and accepted by the payment network.
  - `Originated`: The ACH transaction has been originated (submitted to the NACHA network). VeriCheck V2 only: the debit has been forwarded to the RDFI.
  - `Verifying`: The ACH processor is verifying the bank account before origination. VeriCheck V2 only: the check runs on the processor's side, before the debit reaches the ACH network.
  - `PartiallySettled`: The ACH transaction has been partially settled. VeriCheck V2 only: a portion of the funds have cleared.
- `reason` (string) required: Operator-supplied justification. Required, trimmed, 5 to 500 chars. (nullable)

## See also

- [All documentation](https://devportal.demo.winkpg.io/llms.txt): the machine-readable index of every public page on this site.