---
title: EFT payment channel eligibility filtering
summary: Produces direct-deposit-eligible and debit-card-eligible subsets of an already-assembled payee collection by checking each payee's current EFT authorization type.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Payment
reference_type: package
operation_id: OP-PAY-02
trigger: Caller reads the DirectDepositEligible or DebitCardEligible property on a populated clsEligPayeeClaimCollection
---

# EFT payment channel eligibility filtering

`DirectDepositEligible` and `DebitCardEligible` are mirror-image read-only properties on `clsEligPayeeClaimCollection` that both filter the same already-populated payee collection by delegating to the same EFT-authorization lookup; they differ only in which authorization type they exclude. They are documented together because they share one implementation pattern, one dependency call, and one business concept — payment-channel eligibility per payee — evaluated in opposite directions.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-PAY-02 |
| **Trigger** | Caller reads `DirectDepositEligible(inClaimID)` to get payees who can receive a check or ACH direct deposit, or `DebitCardEligible(inClaimID)` to get payees who can receive a debit-card payment |
| **Inputs** | An already-populated `clsEligPayeeClaimCollection` (via [Get eligible claim payees](get-eligible-claim-payees.md)); `inClaimID As Decimal` |
| **Outputs** | A new `clsEligPayeeClaimCollection` containing only the payees eligible for the requested channel |
| **Primary components** | `clsEligPayeeClaimCollection.DirectDepositEligible`, `clsEligPayeeClaimCollection.DebitCardEligible` |
| **Entry point** | `Business\SAIF.Business.Payment\clsEligPayeeClaimCollection.vb` |

## Steps

1. **Start a new empty collection.** Each property constructs a fresh `clsEligPayeeClaimCollection` (`newList`) to hold the filtered result, leaving the source collection unmodified.
2. **Iterate every payee in the source collection.** For each `clsEligPayeeClaim` in `List`:
   - **Blank placeholder passthrough.** If `payee.PersonID <= 0` (the blank "no payee selected" sentinel added by [Get eligible claim payees](get-eligible-claim-payees.md)), the payee is added to `newList` unconditionally, with no authorization lookup performed.
   - **Real payee — resolve current EFT authorization type.** If `payee.PersonID > 0`, the property calls `EFTServices.GetEFTAuthorizationType(MyCriteria.DataPortalInfo, inClaimID, payee.PersonID, , True)`, passing the claim ID, the payee's person ID, the default worker customer-type code, and `inIncludePendingAuthorizations = True`.
     - `GetEFTAuthorizationType` delegates to `ActiveClmPersonEFTAuthSeq`, which checks for an active direct-deposit authorization sequence first and, only if none is found, checks for an active debit-card enrollment, returning whichever type (or `NotAuthorized`) applies.

     > **Origin**: The EFT authorization type lookup is implemented by [`EFT authorization support`](../../saif-business/operations/eft-authorization-support.md) (`SAIF.Business`) and executed on behalf of this operation for each real payee.
   - **`DirectDepositEligible` filter test.** The payee is added to `newList` unless the resolved authorization type equals `DebitCard` — i.e., a payee already committed to debit-card payment is excluded from the direct-deposit-eligible set.
   - **`DebitCardEligible` filter test.** The payee is added to `newList` unless the resolved authorization type equals `DirectDeposit` — i.e., a payee already committed to direct-deposit payment is excluded from the debit-card-eligible set.
3. **Return the filtered collection.** After all payees have been evaluated, the property returns `newList` to the caller as the channel-specific eligible subset.

## Process flow

The following diagram visualizes this operation's control flow. The same flow applies to both properties; only the excluded authorization type differs (shown in brackets).

```mermaid
flowchart TD
	Start([Caller reads DirectDepositEligible<br>or DebitCardEligible]) --> NewList[Create empty result collection]
	NewList --> Loop[For each payee in source collection]
	Loop --> Blank{PersonID <= 0<br>blank placeholder?}
	Blank -->|Yes| AddBlank[Add unconditionally]
	Blank -->|No| Lookup[Call GetEFTAuthorizationType]
	Lookup --> Exclude{Auth type matches<br>excluded type for this property?}
	Exclude -->|Yes: DirectDeposit excludes DebitCard;<br>DebitCard excludes DirectDeposit| Skip[Skip payee]
	Exclude -->|No| Add[Add payee to result]
	AddBlank --> More
	Add --> More
	Skip --> More{More payees?}
	More -->|Yes| Loop
	More -->|No| Done([Return filtered collection])
```

## Failure and edge-case behavior

- Both properties treat a `PersonID <= 0` blank placeholder as always eligible for either channel; the placeholder is never checked against `EFTServices.GetEFTAuthorizationType`, so it always survives both filters.
- `inIncludePendingAuthorizations = True` is hard-coded in both calls, so a pending (not-yet-active) authorization of the opposing type is enough to exclude a payee from a filter — the filters do not distinguish between a fully active and a pending authorization of the excluded type.*
- Neither property checks `iPaymentPreference.AllowDebitCard`; whether a payee's implementing payment-preference object ultimately offers the debit-card channel to the user is governed separately by that contract member ([BR-PAY-02](../business-rules.md#br-pay-02-conditional-debit-card-allowance)), which is enforced outside this library.
- The two filters are mutually informative but not mutually exclusive at the collection level: a payee with `AuthorizationType.NotAuthorized` or `ProviderDirectDeposit` passes both filters, because neither filter's excluded-type check matches those values.*
- Filtering operates on whatever collection the caller passes as `Me` (the `List` property); if the source collection has not been populated by [Get eligible claim payees](get-eligible-claim-payees.md), the filtered result will simply be empty or contain only the blank placeholder.*

## Related documentation
- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts.

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