Platform
Card types and what each one does to a limit
Main, supplementary, virtual, corporate, digital and prepaid — six kinds of card on one platform, and the limit rule is different for every one of them.
Read from the Issuing services operation by operation in October 2026 — the limit engine, the virtual card path, the supplementary realignment and the prepaid wallet reference. Every rule below was found in code rather than inferred from a field name, and where a rule differs between credit and the other programmes the difference is stated rather than averaged.
- Whether a bank may hold more than one virtual card per main card, and whether the three-pool rule changes when it does.
- How the corporate limit pool is configured, since no published operation reads or writes a company-level allocation.
A bank runs one platform and issues six recognisably different things on it. They share the card record, the status model and the PIN machinery; what separates them is what a limit means for each. That is the axis worth learning, because it is the one that decides which operation you call and what it is allowed to do.
The six kinds
Card kinds · how each relates to a limit
| Kind | What it is | Its limit |
|---|---|---|
| Main | The customer's own card; the one the statement belongs to | Draws from the customer's limit and has its own |
| Supplementary | A second person on the main card | Shares the main card's pool. Can hold a lower sub-limit; cannot exceed the main card |
| Virtual | No plastic, usually for e-commerce | Derived from the main card, and bounded by three pools at once |
| Corporate | Issued to a company, with a card hierarchy under it | Bound to the company allocation; its own rules, its own operations |
| Physical / digital | The same card in two form factors | One card record, one limit; the digital side may compute its own figure |
| Prepaid | Spends a loaded balance | No limit at all — see below |
The pairs are what catch people. Main and supplementary are two cards and one pool. Physical and digital are one card in two forms. Reading the second pair as the first is how a team ends up looking for a limit that was never separate.
The limit is three levels deep, and only one of them propagates
The customer's limit is the ceiling for everything they hold. A main card sits under it. A supplementary or virtual card sits under the main card.
Changing the customer limit writes the customer level and nothing else — no card moves. Pushing a reduction down to the cards is a different operation, and it is the one that walks every main card and then every supplementary card still sitting above the new figure.
Virtual cards · three pools, not one
A virtual card's requested limit is checked against the related card's available limit, the main card's, and the customer's. Exceeding any one of the three refuses the request. A virtual card also carries no cash advance limit — every cash figure is zero — and its limit can be time-boxed: a fixed limit clears at the end of the day or on the related card's statement date, which is what makes a single-use card possible.
A limit is not one number
Four dimensions are tracked separately, and an integration that reads only the first will report a card as having room it does not have.
- Spending — the headline figure, and what most screens mean by "limit".
- Cash advance — its own allowance, and it is not entered directly: it is derived from a ratio of the spending limit, with local and foreign currency held apart.
- Instalments — the slice available to instalment plans.
- Contactless consecutive — how many contactless transactions may run before a PIN is demanded. A count, not an amount.
And beside all four sits a fifth thing that is not a limit at all: the used amount. The limit is what the bank allocated; the used amount accumulates from transactions, and no limit operation writes it.
Operation limits are a different layer
The limits above answer how much. A second, separate layer answers where, how and how often — and it lives in its own table with its own operations. One row is keyed by five things at once: transaction group, main group, channel, network and event. At customer level the key is wider still, taking the merchant category and its group, and adding a yearly period to the per transaction, daily, weekly and monthly ones.
Two consequences worth carrying:
- A row can only be written where the parameter for that key allows customisation. Where it does not, the request is refused for that row alone.
- These calls take many rows at once and each row answers for itself, so a 200 does not mean every row was applied.
Prepaid has none of this
There is no allocated limit on a prepaid card. What can be spent is a loaded balance, the card refers to a wallet through its shadow card number, and one wallet can hold more than one balance — by currency or by purpose. So the credit vocabulary of increase, decrease and reset has no counterpart here; the prepaid verb is load.
What is not published
Loading funds, card-to-card transfer and reading a wallet balance have no published operation on this portal. A prepaid programme can be issued, registered, PINned and embossed through these APIs; the money side comes from elsewhere. It is stated here rather than left for an integration to discover.
Everything else about a prepaid card — status, PIN, embossing, delivery, operation limits — behaves exactly as it does on credit and debit.