Card lifecycle
Move a card through its states after issuance — status changes, replacement, renewal, blocking and closure.
getPrepaidCardInfo
Retrieves detailed information about a prepaid card.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getPrepaidCardInfo › 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, naming both.
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 resolved and overwrites the other.
getPrepaidCardInfo › Responses
One card's detail. Sensitive data is filled only for a digital or virtual card; on a physical one it is null.
This operation refuses rather than answering empty: a card with no information record is a 400, not a 200 with an empty body.
The card the operation is answering about.
changeAndReplaceCard
Changes and replaces a prepaid card, updating associated data.
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 to change and replace. Checked here, in the first of two validation passes.
How the replacement is to be made. Checked in two passes: this field's presence first, and only then the embossing reason and sub-reason inside it. So a request that is missing both this and an embossing reason is refused for this one alone, and the second refusal only appears once this is sent.
cardStatusCodeRequired in practice — The status to move the card to before it is replaced. Not checked in either pass — the status change is the first of the two service calls and refuses it there.
Values:
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
Both halves done. The status change and the replacement are two calls to the lifecycle service, and they run in one transaction: a failure in either rolls the whole thing back, so there is no state where the card was closed but not reissued.
The response carries both answers — toStatusActive from the status change, and the new card's references with newCardGenerated and productChanged under replaceResult.
toStatusActiveWhether the card ends this operation in an active status.
What the replacement produced.
changeCardStatus
Changes the status of a prepaid card.
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.
shadowCardNumberRequired in practice — The card whose status changes. Not validated here — the facade forwards every field untouched, so an absent or unknown value is refused by the prepaid lifecycle service in its own vocabulary rather than as a missing field.
cardStatusCodeRequired in practice — The status to move the card to. The transition itself is checked behind this API, against the channel group and the platform's transition matrix; sending the status the card already holds is refused rather than treated as a no-op.
Values:
A— validB— pendingC— stolenD— cancelled by the bankF— fraudG— temporarily blockedI— cancelledL— lostM— cancelled by the customerT— corporate dummy
cardStatusReasonCodeRequired in practice — Why the status changes. It is checked as a pair with cardStatusCode — a reason that does not belong to the status is refused.
closeRequestDateConditional — When a closure was requested. Forwarded untouched; it is read by the closing transitions rather than by every status change.
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
Changed. The response is one flag, toStatusActive, saying whether the card ended up in an active status — not the status itself. Read the card back if the code and reason matter.
Clearing a PIN or verification-value counter does not lift a status that a run of failed attempts caused; this operation is what moves a card out of it.
toStatusActiveWhether the card ends this operation in an active status.
replaceCard
Replaces a prepaid card with a new one.
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.
shadowCardNumberRequired in practice — The card being replaced. Not validated here; the facade forwards it and the lifecycle service refuses an unknown one.
embossNameThe name embossed on the card. The services truncate to 26 characters before writing rather than refusing a longer one, so a name that matters should be checked at 26.
deliveryTypeValues:
P— by postS— to the branch
Not set is "".
deliveryAddressTypeValues:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
deliveryBranchCodeThe branch the card is delivered to.
cardEmbossReasonRequired in practice — Why the card is reissued, with cardEmbossSubReason under it. Neither is checked here — unlike changeAndReplaceCard, which validates both before forwarding anything.
Values:
N— new cardY— renewal
cardEmbossSubReasonValues:
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 ---.
productNumberReissue onto a different product. The response's productChanged flag is what says whether it took effect.
instantIssuingFlagWhether the card is issued over the counter rather than produced and delivered.
embossBranchCodeThe branch the card is embossed for.
What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.
cardSendAddressIdA stored address for the new card, mapped to a single-entry address list. Omitted, no list is sent.
replaceCard › Responses
Replaced — and two flags say what actually happened, which a status code cannot. newCardGenerated says whether a new card was produced at all, and productChanged whether productNumber moved it. A 200 with both false is a call that changed nothing.
The new card's references come back beside them; the old card's options and permissions are carried across by the platform rather than by this request.
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.
getCardList
Retrieves the list of prepaid cards for a customer.
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.
isCorporateAllCardListOptional · Default false — Return every card under the corporate hierarchy. True discards customerNumber: the facade clears it before the read, so a request carrying both does not narrow to that customer. mainCustomerNumber is what scopes a corporate listing.
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.
cardNumberA PAN to find the card by. It is resolved to a shadow card number before anything else runs, and a PAN that matches no card is refused with 20008 rather than returning an empty list — the one input here that fails rather than filters.
purposeNarrows the listing by the cards' purpose. It is not a criterion on its own: see the 200 description — a request carrying only this field answers with an empty list.
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, against the normalised search copy of it rather than the name on the card: uppercased, accents folded, and matched as a fragment.
identificationNumberMatches the customer's tax number or national identity number. The query compares the first ten characters of one and the first eleven of the other, so a longer value finds nothing rather than being refused.
courierStatusNarrows the listing by where the card is in delivery. One of the eight fields that counts as a criterion.
getCardList › Responses
A list, and an empty one is not the same as none found.
The read runs only when at least one of eight criteria is present — the shadow card number (or a PAN resolved into one), the customer or main customer number, the barcode, the branch code, the name, the identity number or the courier status. With none of them the repository is never asked and the answer is an empty list with a 200. purpose is not among the eight: sent alone, it filters nothing because nothing is read.
The channel has a default here. Left out, channelCode is substituted with a built-in value before the cards are read — the only operation on this API that fills the channel in for the caller. It is the channel the card's sensitive data is fetched under, so it is worth sending deliberately.
Two things in each row are conditional rather than absent when empty. Sensitive data is filled only for a digital or virtual card; on a physical one it is null. And barcode comes back only for a card whose status reason marks it blocked and which is not digital — on every other card the field is null even though the card has one.
The cards the search matched.