Card applications
Track a card application from submission to the card being produced.
getCardApplicationList
Retrieves the list of card applications for a specific customer. Uses CustomerNumber and optional ApplicationId as input. For each application, includes account details (balance, usable balance, currency, branch, IBAN) and error information if fetching account balance fails.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardApplicationList › Request Body
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
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.
getCardApplicationList › Responses
Success
getDebitApplicationIdByFromShadowCardNumber
Retrieves debit card replacement application information using the source shadow card number. Fetches card master data, then queries replacement application records. Returns application ID derived from correlation ID or record ID and the application date if available.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getDebitApplicationIdByFromShadowCardNumber › 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.
getDebitApplicationIdByFromShadowCardNumber › 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.
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.
submitCardApplicationExtStatus
Submits a card application and returns extended status information. Used to track application processing in debit channels.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
submitCardApplicationExtStatus › 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.
applicationIdCard application the status belongs to. Refused when absent and refused again when zero. Not checked against the application table — an id that matches no application is accepted and stored.
externalStatusCodeThe application's status in the external system that owns the process. One character, and the length is checked before anything is written rather than left to the column.
The codes are the submitting system's own. Nothing resolves this value against a parameter table or an enumeration: it is compared with the stored value for inequality and written through, so any single character is accepted. The one code the platform writes itself is X, set by the no-name application expiry batch when it cancels an expired pending application. A bank's own codes may use it or not.
Submitting any status also moves the clock the application expires on: the expiry batch measures a pending application from the last write to this record against the ExternalStatusExpirePeriod parameter, and only from the application date against DefaultExpirePeriod where there has been no submission.
submitCardApplicationExtStatus › Responses
Submitted. cardApplicationExtStatusHistoryRecordId is the history row written for this change, and it is 0 when the submitted code equals the one already stored — that case writes nothing at all and is reported as a success, so a caller treating the id as proof of a write has to test it.
cardApplicationExtStatusHistoryRecordId