# AdjustmentTypes

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

Per-processor advertised support for the two adjustment-shaped follow-up operations
against an authorized transaction. A processor may legitimately support either, both,
or neither. It is modeled as a [Flags] enum so capability contributors compose cleanly and
callers can ask "does this processor support `X`" with a single `HasFlag`. Values combine: send one or more member names separated by a comma and a space, or the integer sum of their values. Responses carry the names.

## Values

| Value | Description |
| --- | --- |
| `None` | Processor advertises no adjustment support. Both OfflineAdjustment and IncrementalAuthorization requests are rejected. |
| `OfflineAdjustment` | Processor accepts TransactionOperationType.OfflineAdjustment: pre-settlement edits to the stored settlement record (tip, tax, level-3, AVS) with no network call. Modeled by OfflineAdjustmentFlowRunner. |
| `IncrementalAuthorization` | Processor accepts TransactionOperationType.IncrementalAuthorization: an online amount-bumping auth on top of the existing approved hold (Visa Estimated/Incremental, MasterCard PreAuth+Final, Discover Incremental). Modeled by IncrementalAuthorizationFlowRunner. |

## See also

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