Card issuance and personalisation
Create individual, corporate and virtual cards, and check which products a customer is eligible to hold before you issue.
getApplicableProductsByCustomerNumber
Retrieves the list of card products applicable to a specific customer. Filters by main customer number and optional product group. Returns product details including name, number, brand, short name, digital capability, and tenant ID.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getApplicableProductsByCustomerNumber › 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 applicable products are read. Three separate refusals — absent, zero and negative each raise their own code.
mainCustomerNumberMain customer to read against. Not required, but when supplied it may be neither zero nor negative.
Which rows to return. Left out, the operation returns them all.
getApplicableProductsByCustomerNumber › Responses
Success
The products the search matched.
createIndividualCard
Creates an individual debit card for a customer, handling product selection, accounts, permissions, digital card flags, addresses, and miscellaneous options. Returns card references, masked and shadow card numbers, warnings, application ID if created asynchronously, and attached account list.
Part of:
- Journey 01 · Launching a new card product — step 2, Issue against accounts
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createIndividualCard › 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.
productNumberThe product the card is issued on. Must be a product the platform defines.
customerNumberThe customer the card is issued to.
branchCodeThe branch the card is issued from. Must be a defined branch.
ListHasNoItem — The accounts the card draws on. Must be sent and must hold at least one entry.
digitalCardFlagWhether to issue the card as a digital one. It also decides the default e-commerce permission where permissions leaves that unset.
nameOnCardThe 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.
cardDeliveryTypeHow the card reaches the cardholder. Branch makes cardDeliveryBranchCode mandatory.
Values:
P— by postS— to the branch
Not set is "".
cardSendAddressTypeValues:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
cardDeliveryBranchCodeConditional · NotNull — The branch the card is delivered to. Mandatory when cardDeliveryType is Branch, and it must be a defined branch.
cardSendAddressIdWhich of the customer's addresses to send the card to. The identifier of an address already held for that customer, not an address.
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.
A miscellaneous option to set on the card, as a type-and-value pair. Only one may be sent at creation; changeCardMiscOption sets more.
Leaving it out does not leave the option unset. No row is written, but getCardMiscOption answers for a card that has none by returning the first value configured for that option type — so the card behaves as if it had been given that value. Which value that is comes from the option-type definition rather than from this API.
Replacing a card carries the option across. Where the replaced card had none, the platform writes DS / HardCopy onto the new one.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
applicationDateA 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.
applicationContractIdThe contract record in the application system that this card comes from.
contractTypeWhich cardholder contract the customer accepted. The pair with contractVersionNumber records what was agreed to and when.
contractVersionNumberWhich version of that contract the customer accepted.
createIndividualCard › Responses
Success
recordIdThe identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.
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.
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.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
createIndividualSupplementaryCard
Create Individual Supplementary Card
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createIndividualSupplementaryCard › 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.
productNumberProduct the card is issued on. Rejected when absent and when it matches no card product. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. Its segment must be Individual: a corporate product is refused here.
customerNumberCustomer the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.
shadowCardNumberThe main card's shadow number. Its master must carry a main customer and that customer must be active.
branchCodeBranch the application is made at. Rejected when absent and again when it matches no branch.
ListHasNoItem — The accounts the card draws on. A debit card is issued against accounts, so an absent or empty list is refused — this is the check credit's equivalent operation does not have.
digitalCardFlagAsk for the card to be issued as digital. Refused when the product has no digital card ability.
nameOnCardThe 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.
cardDeliveryTypeValues:
P— by postS— to the branch
Not set is "".
cardSendAddressTypeWhich address the card is sent to. Only checked when supplied, and then it may not resolve to None.
Values:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
cardDeliveryBranchCodeConditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is the branch delivery type, and ignored otherwise.
cardSendAddressIdWhich of the customer's addresses to send the card to. The identifier of an address already held for that customer, not an address.
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.
A miscellaneous option to set on the card, as a type-and-value pair. Only one may be sent at creation; changeCardMiscOption sets more.
Leaving it out does not leave the option unset. No row is written, but getCardMiscOption answers for a card that has none by returning the first value configured for that option type — so the card behaves as if it had been given that value. Which value that is comes from the option-type definition rather than from this API.
Replacing a card carries the option across. Where the replaced card had none, the platform writes DS / HardCopy onto the new one.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
applicationDateApplication Date
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.
applicationContractIdThe contract record in the application system that this card comes from.
contractTypeWhich cardholder contract the customer accepted. The pair with contractVersionNumber records what was agreed to and when.
contractVersionNumberWhich version of that contract the customer accepted.
createIndividualSupplementaryCard › Responses
Success
recordIdThe identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.
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.
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.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
createCorporateCard
Creates a corporate debit card for a customer, handling product selection, accounts, delivery options, permissions, and digital card flags. Returns card references, masked and shadow card numbers, warnings, and application ID if created asynchronously.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createCorporateCard › 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.
productNumberProduct the corporate card is issued on. Rejected when absent and when it matches no card product. Its segment must then be Corporate: an individual product is refused here. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. A product that issues virtual cards is refused outright — this operation does not create them.
customerNumberCustomer the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.
shadowCardNumberThe main card's shadow number.
digitalCardFlagAsk for the card to be issued as digital. Refused when the product has no digital card ability.
nameOnCardThe 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.
secondNameOnCardThe second embossed line, used for the company name on a corporate card.
branchCodeRequired in practice · NotNull — Branch the application is made at. Unlike the sibling create operations this one does not demand it up front — it is checked by lookup, so an absent value is refused as a branch that was not found.
cardDeliveryTypeValues:
P— by postS— to the branch
Not set is "".
cardSendAddressTypeWhich address the card is sent to. Only checked when supplied, and then it may not resolve to None.
Values:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
cardSendAddressIdWhich of the customer's addresses to send the card to. The identifier of an address already held for that customer, not an address.
cardDeliveryBranchCodeConditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is the branch delivery type, and ignored otherwise.
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.
The accounts to attach to the card as it is created. Each entry carries the account's own identifiers; attaching one later is attachCardAccount.
applicationDateA 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.
applicationContractIdThe contract record in the application system that this card comes from.
createCorporateCard › Responses
Success
recordIdThe identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.
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.
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.
mainShadowCardNumbercardRefNumberThe 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.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
createDummyCorporateCard
Create Dummy Corporate Card
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createDummyCorporateCard › 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 the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.
productNumberProduct the card is issued on. Rejected when absent and when it matches no card product. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. Its segment must be Corporate: an individual product is refused here.
branchCodeBranch the application is made at.
digitalCardFlagAsk for the card to be issued as digital. Refused when the product has no digital card ability.
cardDeliveryTypeValues:
P— by postS— to the branch
Not set is "".
cardSendAddressTypeWhich address the card is sent to. Only checked when supplied, and then it may not resolve to None.
Values:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
cardDeliveryBranchCodeConditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is supplied and is the branch delivery type — this operation checks for an empty delivery type first, which its siblings do not.
nameOnCardThe 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.
applicationDateApplication Date
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.
createDummyCorporateCard › Responses
Success
cardMasterRecordIdsecureCardMasterRecordIdcardRefNumberThe 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.
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.
createVirtualCard
Creates a virtual debit card linked to an existing shadow card, handling accounts and Masterpass enrollment. Returns card references, masked and shadow card numbers, attached accounts, warnings, and sensitive card data including PAN, CVV, and expiry date.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createVirtualCard › 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 related card's shadow number — the card the virtual card draws on. Its status must allow one, and the customer may hold only one virtual card per related card.
ListHasNoItem — The accounts the card draws on. A debit card is issued against accounts, so an absent or empty list is refused — this is the check credit's equivalent operation does not have.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
createVirtualCard › Responses
Success
recordIdThe identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.
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.
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.
relatedCardRefNumberThe card this one is related to, where it is.
What the operation wants to say about work it did anyway. A warning does not mean the operation failed.
The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.
getPendingCardEmbossList
Retrieves pending embossing information for a debit card using its shadow card number. Returns details including card sequence, emboss and application dates, reason codes and descriptions, emboss status, product type, masked card number, shadow card number, and validity flag.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getPendingCardEmbossList › Request Body
shadowCardNumberThe card whose pending emboss records are listed. The only field the request carries, and the only thing checked.
getPendingCardEmbossList › Responses
Success
cardSeqNumberWhich chip on the card was used, where a customer holds more than one card on the same number.
embossDateA 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.
applicationDateA 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.
embossReasonCodeValues:
N— new cardY— renewal
embossReasonDescriptionThe description of embossReasonCode, carried alongside it for display. It is not a key: match on the code.
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 ---.
embossReasonSubDescThe description of embossReasonSubCode, carried alongside it for display. It is not a key: match on the code.
embossStatusValues:
W— waitingP— processingC— emboss file createdE— embossedT— PIN printedD— deliveredR— emboss file removedF— emboss faultyN— emboss not completedX— error
Not set is "".
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.
productTypeCodeValues:
C— creditD— debitP— prepaid
productTypeDescriptionThe description of productTypeCode, carried alongside it for display. It is not a key: match on the code.
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.
validFlagWhether the row is live. The platform sets it; a value sent here is replaced.
cancelCardEmbossByShadowCardNumber
Cancels the embossing of a debit card using the shadow card number and channel. Logs the operation and validates the request before processing.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
cancelCardEmbossByShadowCardNumber › 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.
shadowCardNumberShadow card number of the card whose pending emboss request is cancelled.
cancelCardEmbossByShadowCardNumber › Responses
Success