Platform concepts

Everything on this portal is one entry point into a larger system. This page is the map: what the pieces are called, how they are divided, and which rules hold everywhere so you do not have to relearn them per endpoint.

How domains are organised

The platform is divided into domains, and a domain into modules. The division is by business subject, not by technical layer — there is no "services tier" holding every service. A card dispute and a card limit live in different domains because a bank thinks about them separately, and they are deployed, versioned and scaled separately for the same reason.

The naming carries the division literally. A solution is named Everest.{Domain}.{Module} — so Everest.Dispute.Management is the management module of the dispute domain. When you see that shape in a header, a log line or an error, the first two segments tell you which team owns it and which service you are talking to.

Two consequences worth knowing before you integrate:

• A domain owns its data. One domain does not read another's tables. Where card issuing needs a customer record it asks the customer domain for it, which is why some operations that look like one call to you are several inside.
• Domains version independently. The seven APIs on this portal carry different version numbers because they are different domains on different release cycles, not because one is behind.

Microservices

Each module is a service: its own process, its own configuration, its own lifecycle. The framework gives every service the same skeleton, which is why the seven APIs behave consistently even though different teams wrote them.

A service starts in a fixed order, and the order explains several behaviours you will meet:

1. Configure — everything the service will ever need is registered. The container is open only here.
2. Verify — the container is locked. Nothing can be registered after this point, which is why a service either has a dependency or fails to start; it never acquires one halfway through a request.
3. Initialize — background work begins: polling threads, event consumers, metrics.
4. Dispose — background work is stopped before the process exits.

Inside a request, a service opens a scope, does its work in a unit of work, and commits. A scope closed without a commit rolls back. This is why a failed call leaves nothing behind: partial writes are not a state this platform can be in.

Background work is separate from request handling. A poll thread does periodic work on a timer, an event consumer reacts to messages, and a cache holds reference data in memory and refreshes on demand — which is what the refreshCache operation on this portal actually does.

Security of information

Sensitive values are encrypted at field level, not only in transit and not only at rest on the disk. A protected field is stored with an ENC: prefix and is decrypted only where it is needed, so a database dump, a log file and a stack trace all carry the ciphertext rather than the value.

What this means for you as an integrator:

• Card data comes back masked by default. An operation returns a masked PAN unless it is one of the few that exist to return the real one, and those are the operations your access request is scoped against.
• Do not log a response body wholesale. Responses that carry a PAN, a CVV or a PIN block are marked on their operation page. Log the reference number.
• Encryption is keyed per environment. A value encrypted in the sandbox is not readable in production, and vice versa. Test data does not migrate.

Data models

Two things are worth understanding about the shape of the data before you read a field table.

The card is not the account. A card is a token of access to one or more accounts, and the link between them is its own thing with its own lifecycle — which is why account linking is a separate capability with its own operations, and why closing a card does not close what it drew on.

The shadow card number is the identifier you will use most. The real PAN appears in very few places. Most operations address a card by its shadow number, a stable internal reference that is safe to store and safe to log. If you are designing a database on your side, that is the column to key on.

Every mutation returns a reference you can reverse with. Limit changes, status changes and financial transactions each return a log id or a reference number, and the reversing operation takes it. This is the platform's answer to idempotency: you do not retry a call, you reverse it and issue a new one.

Capabilities

A capability is what this portal navigates by — a thing a bank can do, such as "change a card limit" or "open a dispute". It is not the same as a service. One capability can span several services, and one service can serve several capabilities.

That split is deliberate and it is why this portal does not navigate by API. The OpenAPI tags in the source specifications put 157 of 489 operations under a single heading and left 115 with no heading at all, which tells a reader nothing. The capability taxonomy on this site was built from each API's own documentation and reviewed by hand instead.

Where a capability is not yet available, this portal names it and says so rather than leaving it out. The coverage marker beside every capability tells you which of the four states it is in — documented, drafted, planned, or available on request — so the map is honest about its own edges.