Card lifecycle
Move a card through its states after issuance — status changes, replacement, renewal, blocking and closure.
getCustomerDebitCardListByTenantId
Returns the list of debit cards for a customer filtered by tenant. Retrieves card data via GetCustomerDebitCardListByTenant, enriches results with account balance information from Core Banking, and determines pending replace status based on renewal flags. Performs request validation and returns GetCustomerDebitCardListByTenantIdResponse containing customer debit card details.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerDebitCardListByTenantId › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberCustomer whose cards are listed. A real null check — the field is nullable, so absence is refused rather than read as zero.
tenantIdWhich tenant's cards to list. Its check is commented out in the facade, and absence is not an error: the query runs instead with a marker the service substitutes for a missing tenant, which asks a different question rather than a wider one. Send it to ask about a named tenant.
getCustomerDebitCardListByTenantId › Responses
Success
getCustomerDebitShadowCardsByTenantId
Returns the list of debit shadow cards for a customer filtered by tenant. Retrieves shadow card information via GetCustomerDebitShadowCardsByTenant and returns card type, masked and shadow card numbers, product details, and card status information after request validation.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerDebitShadowCardsByTenantId › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberCustomer whose shadow cards are listed. A real null check.
tenantIdWhich tenant's cards to list. Demanded here, unlike on getCustomerDebitCardListByTenantId, where the same check is commented out. The two operations differ on this field.
getCustomerDebitShadowCardsByTenantId › Responses
Success
changeCardStatus
Changes the status of a debit card using status code, reason, and optional transaction information. Returns whether the card status is active after the change.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
changeCardStatus › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
shadowCardNumberThe card whose status changes.
statusCodeThe status to move to. Must be a status the platform defines, and the move must be permitted for this channel group.
Values:
A— validB— pendingC— stolenD— cancelled by the bankF— fraudG— temporarily blockedI— cancelledL— lostM— cancelled by the customerT— corporate dummy
statusReasonCodeDependent — The reason for the new status. Must be a reason defined for statusCode.
transactionIdThe caller's own id. Echoed back in the error body.
closeRequestDateThe date the closure was requested.
A date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.
changeCardStatus › Responses
Success
toStatusActiveWhether the card ends this operation in an active status.
getCardList
Retrieves the list of debit cards based on multiple filters such as ShadowCardNumber, CustomerNumber, MainCustomerNumber, Barcode, AccountNumber, BranchCode, CustomerNameSurname, IdentificationNumber, and CourierStatus. Supports corporate cards, active cards, and digital card flags. Returns a list of DebitCardModel including card details, sensitive data when applicable, account information via ListCardAccountByShadowCardNumber, card status logs, delivery information, and PIN setup status. Uses _dcidRepository.GetSearchByCustomernumberCardnumber for searching, _dbtServiceProxy for account and permission operations, _customerServiceProxy for card and PAN retrieval, and GetSensitiveData for retrieving sensitive card data such as CVV2.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardList › Request Body
channelCodeThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
mainCustomerNumberThe main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
barcodeThe delivery barcode the consignment is tracked by.
accountNumberThe account at the bank's core banking system that the card draws on. It must already exist, belong to the card's customer, and be neither shared nor a foreign-currency account.
cardNumberThe card number, which this API neither stores nor searches on. The facade resolves it through the customer service and searches on the shadowCardNumber that comes back.
purposeNarrows the list by what the cards are wanted for. One letter, compared in the query itself; anything that is not one of the five below filters nothing rather than being refused.
B— cards in a valid statusC— open cards, statusAD— usable cards, and cards in statusGE— closed cards other thanGF— cards that may be reissued
tenantIdWhich tenant's records to read. Omitting it reads the rows that belong to no tenant rather than all of them.
isCorporateAllCardListWhether to return every card of the corporate relationship rather than the customer's own.
branchCodeThe branch the card is opened at, as a number. Held as a number rather than text throughout.
customerNameSurnameMeant to match part of the cardholder's name.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
identificationNumberMeant to match the customer's tax or national identity number.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
courierStatusMeant to narrow the list to cards whose consignment is at this courier status.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
getCardList › Responses
Success.
No field of this request is mandatory and none is validated. The operation is a search: it builds a query from whatever filters are supplied, and a request that supplies none asks for everything the channel may see.
A search that matches nothing is a 200 with an empty list, not a refusal. The facade returns as soon as the card query comes back empty, so there is no business code for "no cards found" and a client must test the list rather than branch on an error.
The answer is assembled from the debit lifecycle and pin services, the CIS online customer service and the facade's own store, so a field being empty can mean the card has no such value or that the source holding it returned nothing. The linked accounts are the clearest case: a card with none and a card whose account lookup came back empty read the same.
The cards the search matched.
getCardListNew
Retrieves the list of debit cards based on multiple filters such as ShadowCardNumber, CustomerNumber, MainCustomerNumber, Barcode, AccountNumber, BranchCode, CustomerNameSurname, IdentificationNumber, and CourierStatus. Supports corporate cards, active cards, and digital card flags. Returns a list of DebitCardModel including card details, sensitive data when applicable, account information via ListCardAccountByShadowCardNumber, card status logs, delivery information, and PIN setup status. Uses _dcidRepository.GetSearchByCustomernumberCardnumber for searching, _dbtServiceProxy for account and permission operations, _customerServiceProxy for card and PAN retrieval, and GetSensitiveData for retrieving sensitive card data such as CVV2.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardListNew › Request Body
channelCodeThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
mainCustomerNumberThe main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
barcodeThe delivery barcode the consignment is tracked by.
accountNumberThe account at the bank's core banking system that the card draws on. It must already exist, belong to the card's customer, and be neither shared nor a foreign-currency account.
cardNumberThe card number, which this API neither stores nor searches on. The facade resolves it through the customer service and searches on the shadowCardNumber that comes back.
purposeNarrows the list by what the cards are wanted for. One letter, compared in the query itself; anything that is not one of the five below filters nothing rather than being refused.
B— cards in a valid statusC— open cards, statusAD— usable cards, and cards in statusGE— closed cards other thanGF— cards that may be reissued
tenantIdWhich tenant's records to read. Omitting it reads the rows that belong to no tenant rather than all of them.
isCorporateAllCardListWhether to return every card of the corporate relationship rather than the customer's own.
branchCodeThe branch the card is opened at, as a number. Held as a number rather than text throughout.
customerNameSurnameMeant to match part of the cardholder's name.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
identificationNumberMeant to match the customer's tax or national identity number.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
courierStatusMeant to narrow the list to cards whose consignment is at this courier status.
Not read on this API. The debit card-list query declares the parameter and then has no block that uses it, so CheckAndChangeDynamicParameter strips it before the statement runs. Credit and prepaid filter on it; here it is accepted and ignored.
getCardListNew › Responses
Success
The cards the search matched.
getCardInfo
Retrieves detailed information for a debit card using either the CardNumber (PAN) or ShadowCardNumber.
Includes card metadata (status, branch, product, owner, expiry, virtual/digital flags, embossing info, sensitive data)
and the list of attached accounts with account balances, usable balances, IBAN, currency, account type/subtype, and error info if fetching fails.
Uses _customerServiceProxy to map PAN to ShadowCardNumber, _dcidRepository for card search, and _coreBankingIntegrationOutdoor for account info.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardInfo › Request Body
shadowCardNumberOne-of — The card to read. Send this or cardNumber; sending neither is refused.
cardNumberOne-of — The card's PAN. Resolved to a shadow card number first, and refused if it matches none. When both are sent this one is used.
getCardInfo › Responses
Success.
cardInfo can come back empty with a 200: the card is looked up, and if what comes back is not the shadowCardNumber that was asked for, the response is returned unfilled rather than refused.
The card the operation is answering about.
replaceCard
Replaces an existing card with a new one. Accepts details such as card emboss reason, product number, delivery information, and optional permissions. Returns the new card information, including masked number, shadow card number, and any warnings.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
replaceCard › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
shadowCardNumberThe card being replaced.
cardEmbossReasonWhy the card is reissued. Renew is the only value this operation accepts; anything else is refused.
Values:
N— new cardY— renewal
cardEmbossSubReasonThe sub-reason under cardEmbossReason.
Values:
BRK— broken cardCHF— damaged chipEXP— renewal at maturityFRD— fraudMGF— magnetic stripe errorNSU— name updateOTH— otherEXO— bulk renewal at maturityLST— lost cardSTL— stolen card
Not set is ---.
embossNameThe name printed on the card.
Declared at 26 on the card master and 30 on the customer asset, so no single width is published. nameOnCard, which the services truncate to 26 before writing, is the field to send a name on.
deliveryTypeHow the card reaches the cardholder. Branch makes deliveryBranchCode mandatory.
Values:
P— by postS— to the branch
Not set is "".
deliveryBranchCodeConditional — The branch the card is delivered to. Mandatory when deliveryType is Branch.
deliveryAddressTypeThe address type the card is sent to.
Values:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
productNumberReissue onto a different product. If sent it must be a product the platform defines; the product change scenario must exist too.
cardSendAddressIdThe stored address the card is sent to.
enrollMasterpassEnrol the new card in Masterpass.
Permissions to carry onto the new card.
replaceCard › Responses
Success
newCardGeneratedWhether the change produced a new card.
productChangedWhether the change moved the card to another product.
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
maskedCardNumberThe card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.
cardRefNumberThe card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
changeAndReplaceCard
Changes the status of a debit card and optionally replaces it with a new card, handling embossing, delivery, and permissions. Returns the updated status and replacement card details.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
changeAndReplaceCard › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
shadowCardNumberThe card being closed and replaced. One call does both, so this is the card the status change lands on and the card the replacement is issued against.
How the replacement card is issued. The object itself is demanded; unlike credit's equivalent, none of its fields is checked here.
cardStatusCodeValues:
A— validB— pendingC— stolenD— cancelled by the bankF— fraudG— temporarily blockedI— cancelledL— lostM— cancelled by the customerT— corporate dummy
cardStatusReasonCodeWhy the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.
closeRequestDateA date and time as a string, in RFC 3339 form: 2026-10-16T14:30:00Z, or with an offset, 2026-10-16T17:30:00+03:00.
changeAndReplaceCard › Responses
Success
toStatusActiveWhether the card ends this operation in an active status.
What the replacement produced.
isCardFoundIn
Checks whether a specific card exists in the system. Accepts a CardNumber and returns a flag (IsFound) along with the ServiceDomainId indicating where the card was found.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
isCardFoundIn › Request Body
cardNumberResolved rather than stored: the facade calls the customer service's getCardByCardNumber with it, takes the shadowCardNumber that comes back and searches on that instead. These services keep no card number column, so the format this has to be in is the customer service's.
isCardFoundIn › Responses
Success
addDebitCardLog
Adds a log entry for a debit card including details like old and new values, card reference, masked number, and validity flag.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
addDebitCardLog › Request Body
channelThree-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.
logCodeWhich kind of log entry is written. The only other field the service demands — the card identifiers are read but not checked, so naming a card that does not exist is a business failure rather than a field one.
cardLogDetailThe detail recorded against the card log entry.
shadowCardNumberThe platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.
cardRefNumberThe card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.
maskedCardNumberThe card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.
customerNumberThe customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.
validFlagWhether the row is live. The platform sets it; a value sent here is replaced.
oldValueThe value before the change, as recorded in the log.
newValueThe value after the change, as recorded in the log.
addDebitCardLog › Responses
Success
recordIdThe identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.