---
title: Query service health and payment/user metadata
summary: Three independent read-only SOAP queries against US Bank — gateway health check, user ID lookup by email, and recurring-payment amount/due-date lookup.
status: draft
owner: SAIF
last_reviewed: 2026-07-30
library: SAIF.Business.EPay.USBank
reference_type: package
operation_id: OP-EPAY-04
trigger: Caller invokes PerformUSBankHealthCheck, GetUserId, or GetPaymentInfo
---

# Query service health and payment/user metadata

These three public methods share no state or sequencing dependency, but are grouped into one operation because each is a single-call, read-only SOAP query with no local persistence, no business-rule enforcement, and near-identical request/response handling. They cover monitoring (health check), resolving a US Bank user ID from an email address, and reading a recurring payment's amount-due and due-date metadata.

| Field | Value |
| --- | --- |
| **Operation ID** | OP-EPAY-04 |
| **Trigger** | Caller invokes `USBankAPIs.PerformUSBankHealthCheck()`, `USBankAPIs.GetUserId(email, isVoluntary)`, or `USBankAPIs.GetPaymentInfo(usBankUser, isVoluntary)` |
| **Inputs** | Health check: none. `GetUserId`: email address, voluntary/assigned-risk flag. `GetPaymentInfo`: `IUSBankUser`, voluntary/assigned-risk flag |
| **Outputs** | Health check: boolean (throws on failure rather than returning false). `GetUserId`: resolved US Bank user ID string. `GetPaymentInfo`: a formatted string combining amount-due and due-date text |
| **Primary components** | `USBankAPIs.PerformUSBankHealthCheck`, `USBankAPIs.GetUserId`, `USBankAPIs.GetPaymentInfo` |
| **Entry point** | `Business\SAIF.Business.EPay.USBank\USBankAPIs.vb` |

## Steps

1. **Health check — call the gateway.** `PerformUSBankHealthCheck` obtains the SOAP client via `GetWebService()` and calls `HealthCheck` with an empty request.
   - On a transport failure: wrap and re-throw as an `ApplicationException`.
   - On a non-zero response code: throw an `ApplicationException` containing the response code and message.
   - Otherwise: return `True`.
2. **GetUserId — build and send the request.** `GetUserId` resolves the biller credential from the voluntary flag, sets the request's `userEmail`, and calls `GetUserID` on the SOAP client.
   - On a transport failure: wrap and re-throw as an `ApplicationException`.
   - On a non-zero response code: throw an `ApplicationException` with the response message.
   - Otherwise: return `GUResponse.userID`.
3. **GetPaymentInfo — build and send the request.** `GetPaymentInfo` resolves the biller credential, sets the recurring-payments product code, sets the `userID` from the US Bank user's sequence number, and calls `GetPaymentInfo` on the SOAP client.
   - On a transport failure: wrap and re-throw as an `ApplicationException`.
   - On a non-zero response code: throw an `ApplicationException` with the response message.
   - Otherwise: build a result string — `"Amount Due is: <amount>"` if `amountDueSpecified`, else `"Amount Due was not specified"`; append `" Due Date is: <date>"` if `dueDateSpecified`, else `" Due Date as not specified"` (note the inverted word order is present in the source text as-is).

## Process flow

The following diagram visualizes the three independent query flows.

```mermaid
flowchart TD
	Start{Which query?}
	Start -->|Health check| HC[Call HealthCheck]
	HC --> HCCode{Response code = 0?}
	HCCode -->|No| HCFail([Throw ApplicationException])
	HCCode -->|Yes| HCOk([Return True])
	Start -->|GetUserId| GU[Call GetUserID with email]
	GU --> GUCode{Response code = 0?}
	GUCode -->|No| GUFail([Throw ApplicationException])
	GUCode -->|Yes| GUOk([Return resolved userID])
	Start -->|GetPaymentInfo| GP[Call GetPaymentInfo with userID]
	GP --> GPCode{Response code = 0?}
	GPCode -->|No| GPFail([Throw ApplicationException])
	GPCode -->|Yes| GPFormat[Format amount-due<br>and due-date text]
	GPFormat --> GPOk([Return formatted string])
```

## Failure and edge-case behavior

- All three calls throw on transport failure and on any non-zero response code — there is no handled/soft-failure path for these queries, unlike `AddBankAccount`'s duplicate-account handling.
- `GetPaymentInfo`'s formatted result is a single human-readable string rather than structured data, so callers must parse it if they need the amount or date programmatically rather than for display.*
- None of these three queries is covered by a catalogued business rule or persists to or reads from the local database.

> **Note:** Statements marked with `*` were inferred from code structure, naming
> conventions, or contextual evidence where direct confirmation was not available
> in source artifacts.

## Related documentation

- [Operations and processes](../operations-processes.md)
- [Business rules](../business-rules.md)
- [SQL catalog](../sql/index.md)
- [Database tables](../database-tables.md)

## Sources

- `Business\SAIF.Business.EPay.USBank\USBankAPIs.vb`