Skip to content

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); 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:
  3. Blank placeholder passthrough. If payee.PersonID <= 0 (the blank "no payee selected" sentinel added by Get eligible claim payees), the payee is added to newList unconditionally, with no authorization lookup performed.

  4. 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) 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).

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), 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, the filtered result will simply be empty or contain only the blank placeholder.*

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