Skip to content

EFT authorization support

This operation centralizes the EFT-authorization checks implemented in EFTServices and the wrapper methods on ClaimServices. The .NET layer mostly orchestrates which pk82350_eft procedure to call and how to interpret the returned sequence numbers and counts.

Field Value
Operation ID OP-SB-08
Trigger Caller invokes EFT helper methods for workers, beneficiaries, providers, or card-enrollment status.
Inputs Claim ID or claim number, person or beneficiary ID, provider ID, auth type, include-pending flag, date
Outputs Authorization sequence, authorization type, count, or boolean
Primary components EFTServices.GetAuthType, EFTServices.IsAuthorizedForEFT, EFTServices.IsBeneficiaryAuthorizedForEFT, EFTServices.IsProviderAuthorizedForEFT, EFTServices.ActiveAuthCountByPerson, ClaimServices.HasActiveWorkerEFTAuth
Entry point Business\SAIF.Business\EFTServices.vb

Steps

  1. Worker-based callers normalize their identifiers by either passing the claim number they already have or substituting the library's compatibility value when only a claim ID is available.
  2. GetAuthType checks for a direct-deposit authorization first and, only if that returns no active sequence, checks for a debit-card enrollment so the caller receives the dominant EFT type in priority order (SQL-035, PAYMENT_AUTHORIZATION).
  3. Person-based authorization checks call pk82350_eft.isauthorizedforeft; when includePending is true the procedure includes pending authorizations, and when it is false the procedure requires an active bank account plus any required prenote success (SQL-019, PROC-RULE-016, PROC-RULE-017, PAYMENT_AUTHORIZATION).
  4. Beneficiary authorization checks call pk82350_eft.isbeneficiaryauthforeft, which succeeds only when the beneficiary authorization is effective, unreversed, and backed by an active bank account (SQL-020, PROC-RULE-018, PAYMENT_AUTHORIZATION).
  5. Provider authorization checks route through the provider procedure and apply the same pending-versus-active gating used by the person-based path (SQL-035, PROC-RULE-019, PAYMENT_AUTHORIZATION).
  6. Active-authorization counts call the count helpers for a person and auth type, preserving the same pending and prenote rules that the sequence lookups use (SQL-035, PROC-RULE-020, PAYMENT_AUTHORIZATION).
  7. Debit-card enrollment checks call CardEnrollmentCountByPerson and treat any non-terminated enrollment as active (SQL-035, PROC-RULE-021, PAYMENT_AUTHORIZATION).
  8. ClaimServices wrappers convert the returned sequence numbers or counts into the boolean answers expected by higher-level claim workflows.

Process flow

The following diagram visualizes this operation's control flow.

flowchart TD
    Start([EFT request]) --> Kind{Worker, beneficiary, provider, or count?}
    Kind -->|Worker| Worker[Call worker authorization helper]
    Kind -->|Beneficiary| Bene[Call beneficiary authorization helper]
    Kind -->|Provider| Provider[Call provider authorization helper]
    Kind -->|Count| Count[Call active-auth or card-count helper]
    Worker --> AuthType{Need auth type?}
    AuthType -->|Yes| Direct[Check direct deposit then debit card]
    AuthType -->|No| Return1([Return worker result])
    Direct --> Return2([Return auth type])
    Bene --> Return3([Return beneficiary result])
    Provider --> Return4([Return provider result])
    Count --> Return5([Return count or boolean])

Failure and edge-case behavior

  • Pending-inclusive checks intentionally bypass bank-status and prenote gating, while active-only checks do not (PROC-RULE-016, PROC-RULE-017).
  • Beneficiary paths return no active authorization when the authorization is reversed, not yet effective, or tied to an inactive bank account (PROC-RULE-018).
  • Debit-card support is only reported when at least one non-terminated enrollment exists (PROC-RULE-021).

Sources

  • Business\SAIF.Business\EFTServices.vb
  • Business\SAIF.Business\ClaimServices.vb