No-name cards
Issue and activate pre-produced cards that carry no embossed name, then bind one to a customer at the point of sale.
createNoNameCardApplication
Creates a no-name debit card application, auto-selecting product and branch if not provided, handling accounts, permissions, and digital card flags. Returns the application ID.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createNoNameCardApplication › 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.
customerNumberThe customer the application is for. Omitted it arrives as 0, which the service refuses, as it does a negative number.
productNumberWhen absent the facade picks a no-name product for the channel, digital or physical as digitalCard asks. Sent, it must be a defined product.
digitalCardDefault — Defaults to false. Read only when productNumber is absent, to pick a digital or a physical no-name product; once the product is known the facade overwrites it from the product's card form.
branchCodeThe branch the card is opened at, as a number. Held as a number rather than text throughout.
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.
correlationIdThe caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
applicationContractIdThe contract record in the application system that this card comes from.
createNoNameCardApplication › Responses
Success
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
cancelNoNameCardApplication
Cancels a no-name debit card application using channel, application ID, correlation ID, and reason for cancellation.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
cancelNoNameCardApplication › 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.
correlationIdThe caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
cancelReasonCodeWhy the application is being cancelled.
cancelReasonTextFree text alongside the cancellation reason.
cancelNoNameCardApplication › Responses
Success
updateNoNameCardApplication
Updates a no-name card application. Allows modification of pending applications without customer name.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
updateNoNameCardApplication › 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.
correlationIdThe caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.
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.
updateNoNameCardApplication › Responses
Success
activateNoNameCard
Activates a no-name debit card for a customer based on channel, last four digits, and barcode. Returns a shadow card number for tracking.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
activateNoNameCard › 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.
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.
lastFourDigitThe last four digits of the card, which pick which of the customer's cards is activated. Matched against the end of the masked card number rather than a stored field of its own, and no length is checked: a shorter value matches more than one card and the operation refuses rather than choosing, while anything longer than the masked number matches nothing.
barcodeThe delivery barcode the consignment is tracked by.
Not read by the service. activateNoNameCard matches the card on customerNumber and lastFourDigit alone — the facade forwards this field and ActivateNoNameCard does not mention it, on credit, debit or prepaid. It is accepted and ignored.
activateNoNameCard › 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.
createCardUsingNoNameApplication
Creates a debit card based on a no-name card application, handling accounts and permissions. Returns card references, masked and shadow card numbers, warnings, and sensitive card data if available.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createCardUsingNoNameApplication › 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.
customerNumberThe customer the card is for. Omitted it arrives as 0, which the service refuses, as it does a negative number.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
correlationIdThe caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.
barcodeThe delivery barcode the consignment is tracked by.
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.
createCardUsingNoNameApplication › Responses
Success
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.
The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.
createAndProcessNoNameCardApplication
Creates and processes a no-name debit card application, handling accounts, permissions, and digital card flags. Returns application ID, card references, masked and shadow card numbers, and sensitive card data if applicable.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createAndProcessNoNameCardApplication › 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 card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.
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.
branchCodeThe branch the card is opened at, as a number. Held as a number rather than text throughout.
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.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
applicationContractIdThe contract record in the application system that this card comes from.
createAndProcessNoNameCardApplication › Responses
Success
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.
The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
replaceNoNameCard
Replaces a no-name card. Determines if the card is digital; if so, calls ReplaceCard, otherwise initiates a ReplaceNoNameCardApplication. Returns application ID, card reference numbers, masked card number, new card generation status, product change status, and shadow card number.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
replaceNoNameCard › 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.
replaceReasonCodeWhy the card is being replaced. It decides what the replacement inherits and whether the card number changes.
enrollMasterpassWhether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.
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.
replaceNoNameCard › Responses
Success
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
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.
newCardGeneratedWhether the change produced a new card.
productChangedWhether the change moved the card to another product.
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.
replaceCardUsingNoNameApplication
Replaces a card using a no-name application. Accepts channel, application ID, barcode, and customer number. Returns the new card details including card reference numbers, masked card number, shadow card number, record ID, warnings, and sensitive card data if available.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
replaceCardUsingNoNameApplication › 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.
customerNumberThe customer the card is for. Omitted it arrives as 0, which the service refuses, as it does a negative number.
applicationIdThe replace application to issue the card from. Omitted it arrives as 0, which matches no application and is refused.
barcodeThe delivery barcode the consignment is tracked by.
replaceCardUsingNoNameApplication › 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.
The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.
changeAndReplaceNoNameCard
Changes the status of a no-name debit card and optionally replaces it or its application, handling digital and non-digital card scenarios. Returns updated status, new card details, and application ID if applicable.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
changeAndReplaceNoNameCard › 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.
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.
What the replacement card should carry — delivery, address and emboss details. Left out, the replacement inherits the card's own.
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.
changeAndReplaceNoNameCard › Responses
Success
toStatusActiveWhether the card ends this operation in an active status.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
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.
newCardGeneratedWhether the change produced a new card.
productChangedWhether the change moved the card to another product.
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.