---
title: SAIF.Business.Payment operations and processes
summary: Operation catalog and cross-operation hub for claim-payee eligibility assembly and payment-channel filtering.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Payment
reference_type: package
---

# SAIF.Business.Payment operations and processes

This page is the operation catalog and cross-operation hub for `SAIF.Business.Payment`. The library defines the `IBankAccount` and `iPaymentPreference` contracts and hosts three in-memory operations built on the claim-payee-eligibility business objects (`clsEligPayeeClaim`, `clsEligPayeeClaimCollection`): assembling the eligible-payee list for a claim, filtering that list by EFT payment channel, and creating a single bare payee record. None of the three operations executes live SQL — all persistence-shaped work is delegated to business objects and services in `SAIF.Business.Claim.Person` and `SAIF.Business`. Each operation's detailed, step-by-step logic lives in its own page under `operations/`.

## Operation catalog

| Operation | Intent | Trigger | Inputs | Outputs | Rules | Tables | SQL |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [Get eligible claim payees](operations/get-eligible-claim-payees.md) | Assemble a populated collection of eligible payees for a claim, applying worker death and beneficiary eligibility rules | `clsEligPayeeClaimCollection.getEligClaimPayees(inDataportal, inWorkerID, inIncludeForeignAddresses, inIncludeNonEligiblePayees, inClaimID)` | `IDataPortalInfo`, `inWorkerID`, `inIncludeForeignAddresses`, optional `inIncludeNonEligiblePayees`, optional `inClaimID` | Populated `clsEligPayeeClaimCollection` | [BR-PAY-01](business-rules.md#br-pay-01-eligible-payee-record-requirement), [BR-PAY-03](business-rules.md#br-pay-03-dead-worker-exclusion-from-eligible-payee-list), [BR-PAY-04](business-rules.md#br-pay-04-child-under-26-eligible-as-beneficiary-payee), [BR-PAY-05](business-rules.md#br-pay-05-invaliddisabled-child-over-26-exception), [BR-PAY-06](business-rules.md#br-pay-06-non-child-beneficiary-eligible-until-award-expiry), [BR-PAY-07](business-rules.md#br-pay-07-include-non-eligible-payees-override) | None | [SQL-001](sql/SQL-001-saif-business-payment.md), [SQL-002](sql/SQL-002-saif-business-payment.md) |
| [EFT payment channel eligibility filtering](operations/eft-payment-channel-eligibility-filtering.md) | Filter an already-assembled payee collection into direct-deposit-eligible and debit-card-eligible subsets | Caller reads `DirectDepositEligible(inClaimID)` or `DebitCardEligible(inClaimID)` on a populated `clsEligPayeeClaimCollection` | Populated `clsEligPayeeClaimCollection`, `inClaimID` | Filtered `clsEligPayeeClaimCollection` (channel-specific subset) | [BR-PAY-02](business-rules.md#br-pay-02-conditional-debit-card-allowance) | None | None |
| [New eligible payee claim](operations/new-eligible-payee-claim.md) | Create a single in-memory eligible-payee record for a given person | `clsEligPayeeClaim.NewEligPayeeClaim(inDataportal, inPersonID)` | `IDataPortalInfo`, `inPersonID` | New `clsEligPayeeClaim` with `PersonID` populated | None | None | [SQL-001](sql/SQL-001-saif-business-payment.md) |

`IBankAccount` and `iPaymentPreference` are interface contracts, not operations — see [API reference](api/index.md) for their member signatures and [Architecture](architecture.md) for their role as component boundaries.

## Process flow diagram

The following diagram shows how the three operations relate: a caller assembles the eligible-payee collection for a claim, optionally narrows it by payment channel, and the worker-record creation step is itself reused internally by the assembly operation.

```mermaid
flowchart TD
	Start([Caller needs claim payees]) --> Get[Get eligible claim payees]
	Get --> Worker[Retrieve worker via SAIF.Business.Claim.Person]
	Get --> Benes[Retrieve beneficiaries via SAIF.Business.Claim.Person]
	Get --> Addrs[Retrieve addresses via SAIF.Business.Claim.Person]
	Worker --> NewPayee[New eligible payee claim<br>worker payee record]
	Benes --> NewPayee2[New eligible payee claim<br>beneficiary payee records]
	NewPayee --> Assembled[Populated collection returned]
	NewPayee2 --> Assembled
	Assembled --> Filter{Caller needs channel-specific subset?}
	Filter -->|Yes| EFT[EFT payment channel eligibility filtering]
	EFT --> Lookup[GetEFTAuthorizationType via SAIF.Business]
	Lookup --> Filtered([Direct-deposit or debit-card eligible subset])
	Filter -->|No| Done([Full collection used as-is])
```

## Inherited operations and processes

Operations in this section originate from base classes or services provided by dependency framework libraries. They are delegated to, not implemented in this library.

### From `clsWorker`, `clsBeneficiaryCollection`, `clsClaimPersonAddressCollection` (`SAIF.Business.Claim.Person`)

| Operation | Intent | Provided by | Origin | Embedded in |
| --- | --- | --- | --- | --- |
| Worker profile management | Retrieve and persist the injured-worker profile via `CCClaimDataApi`† | `clsWorker` | `SAIF.Business.Claim.Person` | [Get eligible claim payees](operations/get-eligible-claim-payees.md) |
| Beneficiary management | Retrieve beneficiary contacts for a worker and lazy-load eligibility/address/guardian data† | `clsBeneficiaryCollection` | `SAIF.Business.Claim.Person` | [Get eligible claim payees](operations/get-eligible-claim-payees.md) |
| Claim-person address management | Retrieve and persist home, mailing, and payment addresses via the worker-address API† | `clsClaimPersonAddressCollection` | `SAIF.Business.Claim.Person` | [Get eligible claim payees](operations/get-eligible-claim-payees.md) |

> **Origin**: These operations are defined in `SAIF.Business.Claim.Person` and consumed by this library. Their step-by-step logic is embedded inline (with `> Origin` callouts) in [Get eligible claim payees](operations/get-eligible-claim-payees.md).

### From `EFTServices` (`SAIF.Business`)

| Operation | Intent | Provided by | Origin | Embedded in |
| --- | --- | --- | --- | --- |
| EFT authorization support | Resolve the current EFT authorization type (direct deposit, debit card, or not authorized) for a person† | `EFTServices` | `SAIF.Business` | [EFT payment channel eligibility filtering](operations/eft-payment-channel-eligibility-filtering.md) |

> **Origin**: This operation is defined in `SAIF.Business` / `EFTServices` and consumed by this library. Its step-by-step logic is embedded inline (with an `> Origin` callout) in [EFT payment channel eligibility filtering](operations/eft-payment-channel-eligibility-filtering.md).

## Database interactions

The following table summarizes which operations read from or write to the database. Per-step SQL and table citations live in each operation's detail page under `operations/`.

| Operation | SQL | Tables | Type |
| --- | --- | --- | --- |
| [Get eligible claim payees](operations/get-eligible-claim-payees.md) | [SQL-002](sql/SQL-002-saif-business-payment.md) | None | Stub (never executed) |
| [New eligible payee claim](operations/new-eligible-payee-claim.md) | [SQL-001](sql/SQL-001-saif-business-payment.md) | None | Stub (never executed) |

Neither SQL ID represents an executable statement: both are non-throwing `RetrieveSQL` property stubs that return a single-space string literal and are never sent to the database by any code path in this library. See [SQL catalog](sql/index.md) and [Database tables](database-tables.md) for details.

## Failure and edge-case behavior
- [Get eligible claim payees](operations/get-eligible-claim-payees.md) returns only the blank placeholder payee when the worker ID does not resolve to an existing worker record.
- [Get eligible claim payees](operations/get-eligible-claim-payees.md)'s `inIncludeNonEligiblePayees` flag overrides the worker death-date exclusion and every beneficiary eligibility check documented in [Business rules](business-rules.md).
- [EFT payment channel eligibility filtering](operations/eft-payment-channel-eligibility-filtering.md) always passes the blank placeholder payee (`PersonID <= 0`) through both filters unconditionally.
- [New eligible payee claim](operations/new-eligible-payee-claim.md) never populates any field besides `PersonID`; callers are responsible for setting all other display and eligibility fields.
- Calling `CreateSQL`, `DeleteSQL`, `InsertSQL`, or `UpdateSQL` on either `clsEligPayeeClaim.Criteria` or `clsEligPayeeClaimCollection.Criteria` throws `ApplicationException` with the `InvalidSQLProperty` message; these operations are intentionally unsupported.

## Related documentation
- [Index](index.md)
- [Overview](overview.md)
- [Architecture](architecture.md)
- [Dependencies](dependencies.md)
- [Business rules](business-rules.md)
- [Database tables](database-tables.md)
- [SQL catalog](sql/index.md)
- [API reference](api/index.md)
- [Configuration](configuration.md)

> **Note:** Statements marked with `†` are derived from dependency library
> documentation via the Legends CLI. They describe inherited behavior from the
> indicated origin library and should be verified if the dependency version changes.

## Sources
- `Business\SAIF.Business.Payment\clsEligPayeeClaim.vb`
- `Business\SAIF.Business.Payment\clsEligPayeeClaimCollection.vb`
- `Business\SAIF.Business.Payment\IBankAccount.vb`
- `Business\SAIF.Business.Payment\IPaymentPreference.vb`