# Everest Card

> The card management platform behind a bank's credit, debit and prepaid
> programmes. Business journeys, a capability map and the API reference.

383 operations across 6 published APIs, 35 capabilities.

## Journeys
- [Launching a new card](/journeys/launch) — 15 steps. Markdown: /journeys/launch/md
- [Managing a card](/journeys/manage) — 15 steps. Markdown: /journeys/manage/md
- [Enabling additional capabilities](/journeys/capabilities) — 9 steps. Markdown: /journeys/capabilities/md

## Payments 101
- [What is a card management system?](/learn/what-is-a-cms) — The engine behind every card in your wallet — and what it actually does all day.
- [The five players in every card payment](/learn/the-players) — Cardholder, merchant, acquirer, scheme, issuer — who does what, and where you sit.
- [Life of a transaction: authorize, clear, settle](/learn/life-of-a-transaction) — Why the money leaves in milliseconds but moves in days — the three phases of every payment.
- [The life of a card](/learn/card-lifecycle) — Design → issue → activate → transact → renew — and the identifiers that follow the card everywhere.
- [Limits, statements and installments](/learn/money-billing) — How credit room works, what a statement really is, and how EPP/IPP/BNPL turn purchases into plans.
- [Declines, reversals and disputes](/learn/when-things-go-wrong) — The unhappy paths — and why each one exists to protect somebody.

## Reference
- [Capability map](/capabilities)
- [API reference](/reference/credit)

## What this platform does not expose
Stated because a model that cannot see an absence will invent a capability.
- Fraud monitoring and reporting: Nine fraud operations exist, all inside the dispute integration service — Mastercard FDA fraud states, issuer fraud lists and fraud record creation. That API is `publish: false` because its own documentation describes a different service, so none of them is reachable yet. Publishing it is a content problem, not a code one.
- Clearing and settlement: Five clearing operations exist in the dispute integration service, which is not published. The business flow behind them is documented — see the clearing and settlement guide — but the endpoints are not yet reachable.
- Wallets: No endpoint in this corpus provisions a card into Apple Pay, Google Pay, Samsung Pay or a bank's own wallet. Wallet provisioning depends on tokenisation, which is also not yet exposed.
- ATM: ATM appears in this corpus only as a limit field on a card and as a dispute case type. No endpoint drives a terminal or an ATM transaction.
- ISO 8583 to REST: The conversion happens inside the platform and is not itself exposed as an API. What can be published today is the field mapping, which is documented from the message structures rather than from an endpoint.
- IVR and call centre: No endpoint here is scoped to an agent or a call. The card operations an agent would use exist, but nothing carries agent identity, call reference or the authentication a call centre journey needs.
- Loan management: Instalments split a card transaction across a schedule; that is documented and real. A loan product with its own origination and account has no endpoint in this corpus.
- Tokenisation: No endpoint in these seven APIs issues, reads or de-tokenises a payment token. The only `token` operations on the platform belong to the OAuth2 security token service, which is a different thing entirely.
- Dashboards and metrics: Everest emits OpenTelemetry metrics that Prometheus scrapes and Grafana draws. The metric families are documented from the framework; this deployment's dashboard inventory is not yet confirmed.
- Events and topics: Everest publishes events over Kafka, RabbitMQ, NATS and HTTP through a common consumer interface. The transport is documented from the framework; this deployment's topic list is not yet confirmed.
- Prepaid balance: loading funds, transfers and wallet balance have no operation.
- Rewards: there is no reward surface.
- Event subscription: there is no webhook surface.

## Data caveats for anything reading the specs
- No field carries maxLength, minLength, pattern or example. Lengths and
  validations are authored, not derivable; where nothing is authored the
  site says 'Not stated' rather than guessing.
- Requiredness is not stated by the specs. The `required` array is a
  Swashbuckle artefact perfectly anti-correlated with `nullable`; do not
  read it as a contract.
- Field descriptions are an echo of the field name in 10,068 of 10,275
  cases. They carry no information.