---
title: EFT authorization / consent
summary: Creates, retrieves (by three variants), updates, and revokes a customer's electronic-payment authorization/consent record.
status: draft
owner: SAIF Doc Gen
last_reviewed: 2026-07-30
library: SAIF.Business.Payment.EFT
reference_type: package
operation_id: OP-EFT-03
trigger: Caller creates a clsEFTAuthorization via NewEFTAuthorization, or retrieves one by AuthorizationSeqNum, AutoPayConfirmationNum, or CustomerID
---

# 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](code-table-lookups.md)) 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](../business-rules.md#br-eft-09-selecting-an-authorization-type-cascades-default-bank-account-attributes)).
   - 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](bank-account-management.md).
3. **Validate before save.** Registered rules check required fields (`BankAccountID`, `CustomerID`, `AuthorizationTypeCode`, `AuthDate`, create audit fields) and code-validity via the linked lookup tables.
4. **Insert.** `BeforeInsert`/`AfterInsert` executes `INSERT INTO PAYMENT_AUTHORIZATION (...)` ([SQL-013](../sql/SQL-013-saif-business-payment-eft.md), [PAYMENT_AUTHORIZATION](../database-tables.md#payment_authorization)).
   - On failure (`RowsAffected <> 1`): adds an `InsertError` message ([BR-EFT-05](../business-rules.md#br-eft-05-insertupdate-operations-require-exactly-one-affected-row)).
5. **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](../sql/SQL-045-saif-business-payment-eft.md), [PAYMENT_AUTHORIZATION](../database-tables.md#payment_authorization)).
   - 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.**
6. **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](../sql/SQL-046-saif-business-payment-eft.md), [PAYMENT_AUTHORIZATION](../database-tables.md#payment_authorization)). Only the filters the caller has set on `Criteria` are included; omitted filters do not constrain the query.
7. **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](../business-rules.md#br-eft-08-authorization-status-is-derived-from-bank-account-and-prenote-state)).
8. **Update.** `BeforeUpdate`/`AfterUpdate` executes a full-column `UPDATE PAYMENT_AUTHORIZATION` keyed on `PaymentAuthorizationSeqNum` ([SQL-081](../sql/SQL-081-saif-business-payment-eft.md), [PAYMENT_AUTHORIZATION](../database-tables.md#payment_authorization)).
    - On failure (`RowsAffected <> 1`): adds an `UpdateError` message ([BR-EFT-05](../business-rules.md#br-eft-05-insertupdate-operations-require-exactly-one-affected-row)).
    - The catalog also documents a delete statement for this table ([SQL-092](../sql/SQL-092-saif-business-payment-eft.md)); normal application flow never calls it, since consent withdrawal is represented as a revoke (update), not a delete.*
11. **Revoke.** `RevokeAuthorization` sets `RevokeDate` and a `RevokeReasonCode` validated against `clsRevokeReasonCode`/`Collection` ([SQL-074](../sql/SQL-074-saif-business-payment-eft.md), [SQL-075](../sql/SQL-075-saif-business-payment-eft.md)), then calls `Save()` (an update via [SQL-081](../sql/SQL-081-saif-business-payment-eft.md), 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.
12. **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

```mermaid
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](../business-rules.md#br-eft-08-authorization-status-is-derived-from-bank-account-and-prenote-state)).
- 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.

## 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. 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`