# Virtual Accounts UAT Limitations & Known Issues

This page describes sandbox-specific behavior for Virtual Accounts in UAT and explains how temporary issues should be published.

## Stable UAT limitations

These are expected UAT behaviors, not production guarantees.

### 1. VAS enablement is client-specific

Having API credentials does not automatically mean your client is enabled for the full Virtual Accounts feature set.

Before testing VAS, confirm that your client has:

- VAS enabled
- the required permissions on its token
- the required account setup for each currency you intend to test


### 2. Currency setup is per client and per currency

Virtual account creation is only available in currencies where your client already has:

- a Settlement Account
- a Parent Account


If one of these is missing, the create job may be accepted but the item result can fail with a currency-provisioning error.

### 3. UAT funding flows may require coordination

Some inbound deposit or settlement scenarios in UAT may require BCB coordination, manual simulation, or customer-specific setup before testing is possible end to end.

If you are validating receive-money flows and do not yet see expected activity, confirm the test method with BCB instead of assuming the deposit endpoints are broken.

### 4. Portal UI and API may not roll out in lockstep

In UAT, the API can be correct even when the portal UI is incomplete or temporarily inconsistent.

If the portal and API disagree:

- trust the API response first
- verify state through `GET /v1/virtual-accounts`
- use direct API calls for create, patch, and job monitoring
- capture the portal behavior separately as a UI issue


## What to do when the portal UI differs from the API

Use this sequence:

1. Reproduce the action with the API.
2. Verify the resulting state with a `GET` endpoint.
3. If the API succeeds, continue your integration using the API result as source of truth.
4. If the UI still differs, record the affected screen, currency, account number, and timestamp and send that with your support request.


For VAS in UAT, API responses should be treated as authoritative unless BCB explicitly tells you otherwise.

## How temporary known issues should be published

Do not publish time-sensitive engineering issues as evergreen product behavior.

Each temporary issue entry should include:

- `Title`
- `First observed`
- `Affected surface`
- `Who is affected`
- `Symptoms`
- `Workaround`
- `API source-of-truth check`
- `Status`
- `Last reviewed`


### Suggested issue template


```md
## [Open] Short issue title

- First observed: 2026-03-12
- Affected surface: Digital Banking Portal Sandbox
- Who is affected: Clients with more than one VAS currency
- Symptoms: Brief description of the visible behavior
- Workaround: Use the API endpoint directly
- API source-of-truth check: `GET /v1/virtual-accounts` returns correct data
- Status: Investigating
- Last reviewed: 2026-03-12
```

### Publishing rules

- Date every entry using absolute dates.
- Publish only confirmed temporary issues.
- Update `Status` and `Last reviewed` whenever the issue is rechecked.
- Remove or archive the entry once resolved.


## Current temporary issues

No temporary issues are documented on this page yet.

Add entries here only after the issue has been confirmed and a workaround or source-of-truth check is known.