Skip to content

Debit card enrollment

clsDebitCardEnrollmentRequest tracks a payee's request to receive payments on a prepaid debit card, and is one of the two child objects a clsPaymentPreference can wrap (see Payment preference selection). Only workers are eligible for debit-card payment per BR-EFT-02; active enrollments are the default retrieval scope per BR-EFT-06.

Field Value
Operation ID OP-EFT-04
Trigger Caller calls NewDebitCardEnrollmentRequest, or retrieves via CardholderIDNum or EnrollRequestSeqNum
Inputs Cardholder ID number, customer ID, participant ID (optional — auto-assigned if omitted), enrollment status/date
Outputs Persisted/updated DEBIT_CARD_ENROLLMENT_REQUEST row; the object is reset to a "new" state after delete rather than marked old
Primary components clsDebitCardEnrollmentRequest.BeforeCreate/Insert/Retrieve/Update/AfterDelete, GetParticipantIDForCardHolderID; clsDebitCardEnrollmentRequestCollection
Entry point Business\SAIF.Business.Payment.EFT\clsDebitCardEnrollmentRequest.vb, Business\SAIF.Business.Payment.EFT\clsDebitCardEnrollmentRequestCollection.vb

Steps

  1. Create a new enrollment request. NewDebitCardEnrollmentRequest fetches the next sequence value (SQL-003, DUAL) and stamps create date/user.
  2. Auto-assign a participant ID if not supplied. If the caller has not set ParticipantID before insert, GetParticipantIDForCardHolderID looks up the participant ID associated with the given CardholderIDNum (SQL-012) and assigns it automatically — the caller is not required to know or supply the participant ID up front.
  3. Validate before save. Registered rules require non-blank CardholderIDNum, CustomerID, ParticipantID (after auto-assignment), and valid create-audit fields; eligibility (AllowDebitCard) is enforced by the calling context per BR-EFT-02, not by this class directly.
  4. Insert. BeforeInsert/AfterInsert executes INSERT INTO DEBIT_CARD_ENROLLMENT_REQUEST (...) (SQL-043, DEBIT_CARD_ENROLLMENT_REQUEST).
  5. The insert parameter builder contains a duplicate AddParm("CardholderIDNum", ...) call — redundant but harmless since the same value is bound both times.*
  6. On failure (RowsAffected <> 1): adds an InsertError message (BR-EFT-05).
  7. Retrieve by CardholderIDNum or EnrollRequestSeqNum. Single-record retrieval selects the full row by whichever key is supplied (SQL-080, DEBIT_CARD_ENROLLMENT_REQUEST).
  8. Collection retrieval excludes terminated enrollments by default. clsDebitCardEnrollmentRequestCollection's default retrieval filters out enrollment rows whose status indicates termination unless the caller explicitly requests an unfiltered (all-statuses) retrieval (SQL-044, DEBIT_CARD_ENROLLMENT_REQUEST, BR-EFT-06).
  9. Update. BeforeUpdate/AfterUpdate executes a full-column UPDATE DEBIT_CARD_ENROLLMENT_REQUEST keyed on EnrollRequestSeqNum (SQL-091, DEBIT_CARD_ENROLLMENT_REQUEST).
  10. On failure (RowsAffected <> 1): adds an UpdateError message (BR-EFT-05).
  11. Delete. BeforeDelete/AfterDelete performs a physical DELETE on the row. Unlike most objects in this library, AfterDelete calls MarkNew() rather than MarkOld() — meaning the object instance is left in a state where a subsequent Save() would attempt to re-insert it (rather than being treated as a fully discarded, "old" object).*

Process flow

flowchart TD
    Start([Caller creates or retrieves<br>a debit-card enrollment]) --> New{New enrollment?}
    New -->|Yes| Seq[Fetch DEBIT_CARD_ENROLLMENT_SEQ.NEXTVAL]
    New -->|No| Retrieve[Retrieve by CardholderIDNum<br>or EnrollRequestSeqNum]
    Seq --> PIDSet{ParticipantID set?}
    PIDSet -->|No| Lookup[GetParticipantIDForCardHolderID]
    PIDSet -->|Yes| Validate
    Lookup --> Validate{IsValid?}
    Validate -->|No| Fail([Broken rules returned])
    Validate -->|Yes| Insert[INSERT DEBIT_CARD_ENROLLMENT_REQUEST]
    Retrieve --> Action{Caller action?}
    Action -->|Update| Update[UPDATE row]
    Action -->|Delete| Delete[DELETE row; MarkNew]
    Insert --> Rows{RowsAffected = 1?}
    Update --> Rows
    Delete --> Rows
    Rows -->|No| Err([InsertError/UpdateError added])
    Rows -->|Yes| Done([Save/Delete returns ErrorCount = 0])

Failure and edge-case behavior

  • Debit-card eligibility (BR-EFT-02) is not enforced inside clsDebitCardEnrollmentRequest itself — a non-worker payee's enrollment could be persisted if the calling context does not check AllowDebitCard first.*
  • Default collection retrievals silently exclude terminated enrollments; callers needing full history must explicitly request the unfiltered variant (BR-EFT-06).
  • AfterDelete calling MarkNew() instead of the conventional MarkOld() is inconsistent with sibling classes in this library and could allow an accidental re-insert if Save() is called again on the same instance after delete.*
  • The duplicate CardholderIDNum parameter binding in the insert builder is redundant but does not change behavior since both bindings use the same value.*

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.EFT\clsDebitCardEnrollmentRequest.vb
  • Business\SAIF.Business.Payment.EFT\clsDebitCardEnrollmentRequestCollection.vb