Card lifecycle
Move a card through its states after issuance — status changes, replacement, renewal, blocking and closure.
getCardList
Retrieves a list of credit cards based on various filters (card number, customer number, main customer number, barcode, account number, branch code, identification, courier status, etc.). Aggregates card product, branch, limit, debt, account info, annual fee, sensitive data (PAN/CVV2), and currency conversion details. Uses parallel async calls for efficiency and maps results to CreditCardModel objects.
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's getCardByCardNumber and searches on the shadowCardNumber that comes back; when the lookup finds nothing the search runs without it rather than refusing.
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
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.
branchCodeThe branch the card is opened at, as a number. Held as a number rather than text throughout.
customerNameSurnameMatches part of the cardholder's name. The query compares it with CARD_MASTER.OWNER_SEARCH_NAME — the normalised copy of the name, not the name on the card — as LIKE '%…%' over an uppercased, accent-folded form, so case and Turkish characters do not have to match and a fragment is enough.
identificationNumberMatches the customer's tax number or national identity number. The query compares it with the first ten characters of one and the first eleven of the other, so eleven is the longest value that can match anything: a longer one is not refused, it simply finds nothing.
courierStatusNarrows the list to cards whose consignment is at this courier status, matched against the delivery integration record.
corpCardFlagWhether to return corporate cards.
onlyLastCardFlagWhether only the most recent card is included.
virtualCardFlagWhether the card is a virtual one.
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 the response 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 facade assembles the answer from five services — card issuing, lifecycle, limit, pin and the CIS online customer service — so a field being empty can mean the card has no such value or that the service holding it returned nothing. Limit and sensitive-card data are the two that most often come back absent.
The cards the search matched.
replaceCard
Replaces a card by generating a new one with specified parameters such as emboss reason, delivery details, and card permissions. Returns the generated card details like masked card number, expiry date, and warnings.
Part of:
- Journey 02 · Managing a card product — step 2, Replace and renew
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.
deliveryTypeHow the card reaches the cardholder. Branch makes deliveryBranchCode mandatory; Post constrains deliveryAddressType.
Values:
P— by postS— to the branch
Not set is "".
deliveryAddressTypeConditional — The address the card is posted to. When deliveryType is Post and this is sent, it may not be None.
Values:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
deliveryBranchCodeConditional — The branch the card is delivered to. Mandatory when deliveryType is Branch.
productNumberReissue onto a different product. If sent it must be a product the platform defines; the product change scenario must exist too.
instantIssuingFlagDefault false — Issue the card at a branch on the spot. True makes embossBranchCode mandatory.
embossBranchCodeConditional — The branch that prints the card. Mandatory when instantIssuingFlag is true.
Permissions to carry onto the new card.
cardSendAddressIdThe stored address the card is sent to.
enrollMasterpassEnrol the new card in Masterpass.
replaceCard › Responses
Success
newCardGeneratedWhether the change produced a new card.
productChangedWhether the change moved the card to another product.
expiryDateA 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.
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.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
getCardMemo
Retrieves a list of card memo entries for a given credit card, filtered by shadow card number, log code, customer number, and date range. Maps results from Lifecycle service to GetCardMemo objects including card reference, masked number, log details, old/new values, insert channel, user, and date.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardMemo › Request Body
startDateCanNotBeNullOrLessThanSqlMinValue — Start of the window the log is read over. Refused when absent, and refused under a second code when it is below the minimum date the platform's store accepts — so a zero or default date is not treated as open-ended.
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.
endDateCanNotBeNullOrLessThanSqlMinValue — End of the window, under the same two rules as startDate.
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.
shadowCardNumberOne-of — The card whose memo log is read. Send this or customerNumber. The two are checked only when both are missing — supply either and neither is validated further.
customerNumberOne-of — The customer whose memo log is read, as the alternative to shadowCardNumber. Zero counts as absent here, so zero with no card number is the case that is refused.
logCodeWhat kind of log entry this is.
getCardMemo › Responses
Success
changeCardStatus
Changes the status of a credit card. Calls the Lifecycle service to update the card status and reason code, optionally reissues the card, and can apply changes only to the specified shadow card. Returns information about the new status, affected shadow cards, card references for limit reset, customer limit reset flag, and a new shadow card number if applicable.
Part of:
-
Journey 01 · Launching a new card product — step 5, Activate and set the PIN
-
Journey 01 · Launching a new card product — step 4, Activate, PIN, transact
-
Journey 02 · Managing a card product — step 1, Status changes
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.
cardStatusCodeThe status to move to. Must be a status the platform defines.
Values:
A— validB— pendingC— stolenD— cancelled by the bankF— fraudG— temporarily blockedI— cancelledL— lostM— cancelled by the customerT— corporate dummy
cardStatusReasonCodeDependent — The reason for the new status. Must be a reason defined for cardStatusCode.
transactionIdThe caller's own id. Echoed back in the error body.
reissueCardDefault false — Reissue the card with the status change.
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.
changeMeOnlyDefault false — Change only this card, not the cards that would follow it.
changeCardStatus › Responses
Success
toStatusActiveWhether the card ends this operation in an active status.
resetCustomerLimitlistOfShadowCardNumberForClosedCardThe cards the operation closed.
listOfCardRefNumberForResetLimitnewShadowCardNumberchangeCustomerCreditCardStatus
Changes the credit card status for a given customer. Validates input parameters, calls the lifecycle service to update card statuses, and returns a list of shadow card numbers for cards that were closed. Supports optional activation of cards and ensures proper rollback and logging on failure.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
changeCustomerCreditCardStatus › 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 moved. Rejected by the facade when absent, and by the service again when zero.
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.
activateCardWhether to activate the card as it is created.
changeCustomerCreditCardStatus › Responses
Success
listOfShadowCardNumberForClosedCardThe cards the operation closed.
changeAndReplaceCard
Changes the status of a credit card and replaces it with a new card if requested. Validates input, executes ChangeCardStatus via lifecycle service, then ReplaceCard via credit issuing service. Returns details about status change and replaced card.
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 required, and two of its fields are checked with it.
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.
resetCustomerLimitlistOfShadowCardNumberForClosedCardThe cards the operation closed.
listOfCardRefNumberForResetLimitWhat the replacement produced.
getRenewCountByShadowCardNumber
Get Renew Count By Shadow Card Number
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getRenewCountByShadowCardNumber › 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 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.
embossReasonSubCodeValues:
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 ---.
getRenewCountByShadowCardNumber › Responses
Success
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.
mainCardRefNumberThe card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.
isSupplementarygetCreditCardInfo
Retrieves detailed credit card information using ShadowCardNumber or CardNumber. Validates input parameters, resolves ShadowCardNumber when CardNumber is provided, and fetches card details including virtual and corporate cards. Returns card information along with card-level and customer-level reward details such as available rewards, reward types, and descriptions.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCreditCardInfo › 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.
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.
getCreditCardInfo › Responses
Success
The card the operation is answering about.
getCustomerCreditCardListByTenantId
Retrieves a list of credit cards for a customer filtered by TenantId and optionally by ProductNumbers. Validates the request, checks card status, filters closed or renewed cards, calculates total debt, fetches statement remaining debt, card limits, and other card attributes. Returns detailed credit card information including masked card numbers, limits, delinquency, due dates, digital card flags, and pending replace applications.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerCreditCardListByTenantId › Request Body
customerNumberCustomer whose cards are listed. A real null check — the field is nullable, so absence is refused rather than read as zero.
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.
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.
productNumbersNarrows the answer to these products; each entry is one product number, at most five characters. An absent or empty list means no filter.
The two operations that take this request match it differently. getCustomerCreditCardListByTenantId keeps a card whose product number contains one of the values, so a prefix or a fragment matches. getCustomerCreditCardListByTenantIdProductNumber keeps a card whose product number equals one, so only the whole number does.
getCustomerCreditCardListByTenantId › Responses
Success
getCustomerCreditShadowCardsByTenantId
Retrieves a list of a customer's credit shadow cards filtered by TenantId. It validates the request, retrieves all shadow cards for the customer from the repository, and returns them with details such as card type, masked number, product info, and status codes/descriptions.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerCreditShadowCardsByTenantId › 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 — the field is nullable, so absence is refused.
tenantIdWhich tenant's cards to list. Demanded here, unlike on getCustomerCreditCardListByTenantId, where the same check is commented out — the two operations differ on this field and the difference is in the source rather than by accident of shape.
getCustomerCreditShadowCardsByTenantId › Responses
Success
getCustomerCreditCardListByTenantIdProductNumber
Retrieves a customer's credit card list filtered by TenantId and optionally by ProductNumber. It validates the request, filters out closed or invalid cards based on status, debt, and digital/physical card rules, and enriches each card with statement remaining debt and available limit information retrieved from the limit service proxy.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCustomerCreditCardListByTenantIdProductNumber › Request Body
customerNumberCustomer whose cards are listed. A real null check — the field is nullable, so absence is refused rather than read as zero.
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.
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.
productNumbersNarrows the answer to these products; each entry is one product number, at most five characters. An absent or empty list means no filter.
The two operations that take this request match it differently. getCustomerCreditCardListByTenantId keeps a card whose product number contains one of the values, so a prefix or a fragment matches. getCustomerCreditCardListByTenantIdProductNumber keeps a card whose product number equals one, so only the whole number does.
getCustomerCreditCardListByTenantIdProductNumber › Responses
Success
getCardListNew
Retrieves a list of credit cards based on various filters (card number, customer number, main customer number, barcode, account number, branch code, identification, courier status, etc.). Aggregates card product, branch, limit, debt, account info, annual fee, sensitive data (PAN/CVV2), and currency conversion details. Uses parallel async calls for efficiency and maps results to CreditCardModel objects.
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.
cardNumberpurposecardStatusCodeValues:
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.
isCorporateAllCardListWhether to return every card of the corporate relationship rather than the customer's own.
tenantIdWhich tenant's records to read. Omitting it reads the rows that belong to no tenant rather than all of them.
getCardListNew › Responses
Success
The cards the search matched.