> ## Documentation Index
> Fetch the complete documentation index at: https://docs.methodfi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Handling Account Edge Cases

> How to handle verification requirements, product limitations, and status changes.

## Handling Account Edge Cases

### 1. Accounts Requiring Verification

Some liability accounts discovered through [Connect](/guides/connect/overview) may appear in `restricted_products` with capabilities that require elevated verification (e.g., an account verification session). This is common for payment-capable accounts where Method needs additional confirmation. Create an [Account Verification Session](/reference/accounts/verification-sessions/create) to unlock these products.

### 2. Product Limitations by Account Type

Not all accounts support all products. Credit cards support [Card Brand](/reference/accounts/card-brands/overview) and [Payment Instruments](/reference/accounts/payment-instruments/overview); auto loans support [Payoffs](/reference/accounts/payoffs/overview); most liability types support [Updates](/guides/updates/overview) and [Balances](/reference/accounts/balances/overview). Always check the `products` array. See the [Liability Types](/guides/accounts/liability-types) page for a breakdown.

### 3. Status Changes Mid-Operation

If an account transitions to `disabled` or `closed` while you have in-flight operations (a pending payment, an in-progress update), those operations may fail. Design your flows to:

* Check account status before initiating operations
* Handle `account.disabled` and `account.closed` [webhooks](/reference/webhooks/overview) gracefully
* Show appropriate UI messages when an account is no longer available

See the [Account Lifecycle](/guides/accounts/lifecycle) guide for status transitions and webhook details.

### 4. Duplicate Accounts

[Connect](/guides/connect/overview) may discover the same underlying account multiple times if the user has accounts reported under slightly different names or through different credit bureaus. Method does attempt to de-duplicate these liability accounts, however instances do occur. Reach out to your CSM if this uncommon event occurs for one of your users.

### 5. Authorized User Accounts

Connect discovers all accounts on a user's credit report, including accounts where they are an authorized user (not the primary holder). The `liability.ownership` field indicates the relationship: `primary`, `authorized`, `joint`, or `unknown`. Consider whether your product should treat authorized-user accounts differently (e.g., payments on authorized-user cards may not be appropriate for [debt consolidation flows](/guides/use-cases/lending/debt-consolidation)).

### 6. Closed / Paid-Off Accounts

Accounts with zero balance or closed status at the financial institution may still appear in Connect results (they remain on the credit report). These accounts will have `status: closed` and limited [product](/reference/accounts/products/overview) availability. Filter them in your UI if they're not relevant to your use case.

### 7. Consent and Data Retention

When an Entity's consent is withdrawn (via the [Consent endpoint](/reference/accounts/consent/withdraw)), their accounts are disabled and data access is revoked. Your application should handle this gracefully — remove the accounts from active views and inform the user.

***

The key principle: design your application to check account status and product availability dynamically, and listen for [webhook notifications](/reference/webhooks/overview) about status changes. Accounts are living objects, and your application should respond to their state changes in real time rather than assuming a static state.

For the full Accounts API, see the [Accounts reference](/reference/accounts/overview).