Skip to content

EFT authorization / consent

clsEFTAuthorization records a customer's consent to receive electronic payments and implements IActiveAutoPayInfo, making it the authoritative source of "is this customer currently authorized/enrolled for auto-pay" queries used elsewhere in the claims system. It supports three distinct retrieval variants and derives its own status from the linked bank account and prenote state rather than storing status directly.

Field Value
Operation ID OP-EFT-03
Trigger Caller calls NewEFTAuthorization, or retrieves via Criteria.RetrieveTypes = AuthorizationSeqNum, AutoPayConfirmationNum, or CustomerID
Inputs Bank account reference, customer ID/second ID/type code, authorization type code, auto-pay confirmation number, prenote flag, effective/revoke dates
Outputs Persisted/updated PAYMENT_AUTHORIZATION row; computed AuthorizationStatus; revoked (RevokeDate populated) row
Primary components clsEFTAuthorization.BeforeCreate/Insert/Retrieve/Update, AuthorizationStatus property, AuthorizationTypeCode setter, RevokeAuthorization; clsEFTAuthorizationCollection.BuildSQL
Entry point Business\SAIF.Business.Payment.EFT\clsEFTAuthorization.vb, Business\SAIF.Business.Payment.EFT\clsEFTAuthorizationCollection.vb

Steps

  1. Create a new authorization. NewEFTAuthorization initializes the object with a create date/user stamp; unlike several sibling objects in this library, the authorization sequence number is generated inline as part of the insert statement itself rather than through a separate DUAL pre-fetch call.*
  2. Assign an authorization type, cascading bank-account defaults. Setting AuthorizationTypeCode looks up the corresponding clsAuthorizationTypeCode (see Code table lookups) and, if the type declares a default banking network or account type, cascades those values onto the linked clsBankAccount unless the caller has already overridden them (BR-EFT-09).
  3. If the cascaded banking network requires ACH standard entry class validation, the linked bank account's NewRoutingNumVerified may be auto-set as part of the cascade — see Bank account management.
  4. Validate before save. Registered rules check required fields (BankAccountID, CustomerID, AuthorizationTypeCode, AuthDate, create audit fields) and code-validity via the linked lookup tables.
  5. Insert. BeforeInsert/AfterInsert executes INSERT INTO PAYMENT_AUTHORIZATION (...) (SQL-013, PAYMENT_AUTHORIZATION).
  6. On failure (RowsAffected <> 1): adds an InsertError message (BR-EFT-05).
  7. Retrieve by AuthorizationSeqNum, AutoPayConfirmationNum, or CustomerID. All three lookup variants share one cataloged SQL entry: Variant A retrieves by PaymentAuthorizationSeqNum; Variant B retrieves by AutoPayConfirmationNum; Variant C calls the stored procedure PK72970_EPAY.retrieve_EFTAuth_ByCustomerID given customer type/ID/second-ID. All three join AUTHORIZATION_TYPE_CODE and left-join REVOKE_REASON_CODE for description text (SQL-045, PAYMENT_AUTHORIZATION).
  8. Variant C's stored procedure could not be confirmed to exist in the target Oracle package during this pass and may be dead/legacy code retained for backward compatibility.**
  9. Collection retrieval with dynamic filters. clsEFTAuthorizationCollection.BuildSQL appends up to 11 optional WHERE fragments in a fixed order — BankAccountID → date range → EnrollRequestSeqNum → CustomerID → CustomerSecondID → CustomerTypeCode → AuthorizationTypeCode → PaymentSourceSystemCode → PrenoteRequiredFlag → active-only → active-recurring-only — then appends ORDER BY auth_date DESC (SQL-046, PAYMENT_AUTHORIZATION). Only the filters the caller has set on Criteria are included; omitted filters do not constrain the query.
  10. Derive authorization status. AuthorizationStatus is a computed (non-persisted) property: it evaluates the linked bank account's status and the authorization's prenote/revoke state to return Active, Pending Prenote, Revoked, or Inactive rather than reading a stored status column (BR-EFT-08).
  11. Update. BeforeUpdate/AfterUpdate executes a full-column UPDATE PAYMENT_AUTHORIZATION keyed on PaymentAuthorizationSeqNum (SQL-081, PAYMENT_AUTHORIZATION).
    • On failure (RowsAffected <> 1): adds an UpdateError message (BR-EFT-05).
    • The catalog also documents a delete statement for this table (SQL-092); normal application flow never calls it, since consent withdrawal is represented as a revoke (update), not a delete.*
  12. Revoke. RevokeAuthorization sets RevokeDate and a RevokeReasonCode validated against clsRevokeReasonCode/Collection (SQL-074, SQL-075), then calls Save() (an update via SQL-081, not a delete) — this makes the authorization no longer active while retaining full history.
    • If the authorization is already revoked, RevokeAuthorization is a no-op and returns without making a further database call.
  13. Dead-code note. DoesAccountHaveAuthorization is declared as a stub that always returns False regardless of input and is never called from any live code path.*
    • Several rule functions related to authorization-type-specific validation are declared but never registered via AddBusinessRules, so they never execute — dead code.*

Process flow

flowchart TD
    Start([Caller creates or retrieves<br>an EFT authorization]) --> Which{Operation?}
    Which -->|New| Seq[Initialize new authorization]
    Which -->|Retrieve by SeqNum| BySeq[SELECT by AuthorizationSeqNum]
    Which -->|Retrieve by ConfirmationNum| ByConf[SELECT by AutoPayConfirmationNum]
    Which -->|Retrieve by CustomerID| ByCust[Call PK72970_EPAY stored proc]
    Seq --> SetType[Set AuthorizationTypeCode]
    SetType --> Cascade[Cascade bank-account defaults]
    Cascade --> Validate{IsValid?}
    Validate -->|No| Fail([Broken rules returned])
    Validate -->|Yes| Insert[INSERT PAYMENT_AUTHORIZATION]
    BySeq --> Status[Derive AuthorizationStatus]
    ByConf --> Status
    ByCust --> Status
    Status --> Action{Caller action?}
    Action -->|Update| Update[UPDATE PAYMENT_AUTHORIZATION]
    Action -->|Revoke| RevokeCheck{Already revoked?}
    RevokeCheck -->|Yes| NoOp([No-op; return])
    RevokeCheck -->|No| Revoke[Set RevokeDate/ReasonCode;<br>UPDATE row]
    Insert --> Rows{RowsAffected = 1?}
    Update --> Rows
    Revoke --> Rows
    Rows -->|No| Err([InsertError/UpdateError added])
    Rows -->|Yes| Done([Save returns ErrorCount = 0])

Failure and edge-case behavior

  • AuthorizationStatus is always computed at read time from the linked bank account and prenote/revoke state — it is never stored, so status changes automatically the moment the underlying bank account status or revoke date changes (BR-EFT-08).
  • The CustomerID retrieval path depends on stored procedure PK72970_EPAY.retrieve_EFTAuth_ByCustomerID, which could not be confirmed present in the current Oracle schema and may be unreachable/legacy code.**
  • RevokeAuthorization is idempotent by design (no-op if already revoked) rather than raising an error on a repeated call.
  • DoesAccountHaveAuthorization is a dead stub always returning False — do not rely on it for authorization-existence checks.*
  • Several authorization-type-specific rule functions are declared in source but never registered, so they have no effect on validation today.*
  • clsEFTAuthorizationCollection.BuildSQL's fixed filter-append order means filters set out of the documented sequence still combine correctly (each is independently optional), but the resulting SQL text always presents WHERE fragments in the same fixed order regardless of which filters were actually supplied.

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 and are flagged as open questions.

Sources

  • Business\SAIF.Business.Payment.EFT\clsEFTAuthorization.vb
  • Business\SAIF.Business.Payment.EFT\clsEFTAuthorizationCollection.vb
  • Business\SAIF.Business.Payment.EFT\clsRevokeReasonCode.vb
  • Business\SAIF.Business.Payment.EFT\clsRevokeReasonCodeCollection.vb