How Everest models a card

• Customer umbrella limit
• Main card limit = customer limit
• Cash limit per card
• Supplementary: ratio or fixed
• Virtual: H decreasing / S fixed

One customer holds an umbrella limit. Main cards draw from it (main card limit = customer limit), each with its own cash limit. Supplementary cards take a ratio or a fixed slice of their main card — ratio-linked limits move automatically when the main card limit changes; fixed limits do not. Virtual cards attach to a main card with their own limit model (decreasing, or fixed with daily / statement reset).

• Parametric status + reason codes
• Cascade close main ↔ supplementary
• G-temporary auto-reopens 24h
• Dual approval option
• Full memo & log on every change

Statuses and reason codes are parametric — your institution defines them, including whether each status allows financial transactions, whether the card can be reissued, and the authorization response code returned while the card sits in that status. Status changes cascade: closing a main card (except lost/stolen or temporary) closes its supplementaries; closing the last supplementary closes the main. Temporary closure (G) auto-reopens after 24 hours (parametric). Permanent closures are final. Dual approval can be enforced on manual status changes.

• Product-level, then card-level
• Event-based limits layer on top
• MCC and country restrictions
• Parametric decline codes

Restrictions apply at product level (all cards on the product) and can tighten further per card. An authorization is refused for any transaction type not permitted at the product level. Restriction checks return parametrically defined response and reason codes. The 21 standard restriction codes are below; event-based limitations (count/amount per period per event) layer on top.

• ATATM
• CBPOS cashback
• CEKCheque payment
• CLSContactless
• DNDomestic cash
• ECE-commerce — full secure
• ENE-commerce — half secure
• EXE-commerce — non secure
• FABill payment
• FFFastFund debt
• MOMail order
• NACash advance
• PPPLoyalty brand (Maximum)
• PTHPreauthorization
• QCQuasi cash
• SAPurchase
• TAInstallment
• TCSPOS cash advance
• VGTax payment
• YDInternational purchase
• YNInternational cash

• shadowCardNumber = card key
• utid = transaction key
• referenceNumber = idempotency

At issuance you receive the shadowCardNumber — the card key for everything that follows. Financial operations return a utid — the transaction key for reversal, installment conversion, disputes and detail. Your referenceNumber makes writes idempotent. Learn these three and the whole API reads naturally.