Get a virtual account
Authorization
OAuth2PasswordBearer In: header
Path Parameters
uuidCookie Parameters
Response Body
application/json
application/json
curl -X GET "https://example.com/api/b/v1/virtual-accounts/497f6eca-6276-4993-bfeb-53cbbbba6f08"{ "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "label": "string", "currency": "string", "scheme": "string", "provider": "string", "account_identifier": "string", "bank_name": "string", "routing_code": "string", "reference_code": "string", "status": "string", "reference_required": true, "created_at": "2019-08-24T14:15:22Z"}Currencies you can open an account in GET
The currencies `POST /virtual-accounts` can open on its own. Most schemes need an account number only the partner can mint, so creating one is really *recording* correspondence you already hold. The currencies listed here are the ones where that is not true — we issue the reference ourselves and there is a live rail behind it — so they are the only ones a business can open unaided. Computed per request from the live rail table, so a corridor going live or a rail being switched off changes the answer without a deploy. Registered above `/{account_id}` on purpose. FastAPI matches in registration order and `options` is a valid UUID path as far as the router is concerned, so the reverse order sends every call here into the by-id handler and answers 422. See `tests/unit/api/test_route_order.py`.
Stop an account collecting POST
Money sent to a disabled account still arrives — the partner does not know it is off. It goes to suspense rather than to the business, and shows up in the ops queue with `account_disabled` against it.