---
title: PaymentOptionsRequestValidator
summary: API reference for PaymentOptionsRequestValidator.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-09-24
library: SAIF.Services
reference_type: package
---

# PaymentOptionsRequestValidator

Validates a `PaymentOptionsRequest`'s check-issue date against three constraints layered together: the date must be present, must not be more than 28 days in the future, must not fall before the next available check-run date for manual (`"MA"`) payment transactions (looked up via `IRepositoryFactory`), and must land on a working day as determined by `IWorkCalendarService`. It depends on `IRepositoryFactory` for repository access to `PaymentTransactionTypeCode` records and on `IWorkCalendarService` for business-day determination.

## Purpose
- Requires `IssueDate` to be non-empty (not the default value).
- When `IssueDate` is set, requires it to be on or after the next available check-run date for the `"MA"` payment transaction type, looked up via `factory.GetRepository<PaymentTransactionTypeCode>()`.
- Requires `IssueDate` to be no more than 28 days beyond today.
- When `IssueDate` is set, requires it to fall on a working day via `IWorkCalendarService.IsWorkingDay`.

## Context
- Namespace: `SAIF.Services.Claims.Bills.Validators`
- Assembly/package: `SAIF.Services` (packaged inside the `SAIF.SAIFCode.Core` NuGet package)

## Public members
| Member | Signature | Purpose |
| --- | --- | --- |
| PaymentOptionsRequestValidator | `PaymentOptionsRequestValidator(IRepositoryFactory factory, IWorkCalendarService workCalendarService)` | Wires required, upper-bound, next-issue-date, and working-day rules for `IssueDate` using repository lookups and calendar service checks.* |

## Behavioral notes
- Validation is enforced via FluentValidation's `AbstractValidator<T>` base.*
- The next-issue-date and working-day rules are both gated behind `When(request => request.IssueDate > DateTime.MinValue, ...)`, so a default/unset date skips those two checks (only the `NotEmpty` and upper-bound rules apply unconditionally).*
- The next-issue-date rule performs a repository query filtered to the `"MA"` payment transaction type code, so its outcome depends on external configuration data rather than only the request's fields.*

## Constraints and usage notes
- Requires both `IRepositoryFactory` and `IWorkCalendarService` implementations to be supplied via constructor injection.

> **Note:** Statements marked with * were inferred from code structure, naming conventions, or
> contextual evidence where direct confirmation was not available in source artifacts. Statements
> marked with ** could not be confirmed; treat as unknown until verified.

## Sources
- Services/SAIF.Services/Claims/Bills/Validators/PaymentOptionsRequestValidator.cs