Reference data
Look up the reference data a card programme is configured against — products, codes and parameters.
getProductByShadowCardNumber
Retrieves product information based on a shadow card number. Returns product brand, card type, product number, product name, product short name, and digital card ability.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getProductByShadowCardNumber › Request Body
shadowCardNumberThe card whose product is returned. It is not format-checked; an absent or unknown value is reported as a missing asset.
getProductByShadowCardNumber › Responses
Success.
The card record is read only to obtain its product number. The owner name, status, expiry date, masked card number and customer number that come back with it are discarded, and nothing about the card itself appears in the response.
The product attributes are then taken from the integration layer's in-memory product cache, not from the database, so a product definition changed since the last cache refresh is reported with its cached values.
cardType0 None, 1 Credit, 2 Debit, 3 Prepaid
digitalAbilityWhether the product can be issued as a digital card.
brandWhich scheme the card is issued on.
productNumberThe card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.
productNameThe card product's full name.
productShortnamegetEmbossReasonSubDefByValidFlag
Retrieves emboss reason sub definitions with their valid and use flags. Calls _pmServiceProxy.GetEmbossReasonSubDefByValidFlag() and maps results to GetEmbossReasonSubDefByValidFlagResponse containing EmbossReasonSubDefList with properties ValidFlag, EmbossReasonSubCode, EmbossReasonSubDesc, and UseFlag.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getEmbossReasonSubDefByValidFlag › Responses
Success.
The operation takes no request body, and the parameter service call behind it takes no arguments either. Every caller gets the same list; the valid-flag filter named in the operation is applied inside the parameter service and cannot be influenced from here.
If the parameter service returns nothing, a null list or an empty list, embossReasonSubDefList is never assigned and the response comes back with no list at all rather than with an empty one, and never as a refusal.
Each definition is re-projected onto exactly four fields: validFlag, embossReasonSubCode, embossReasonSubDesc and useFlag.
getAvailableEmbossReasonList
Retrieves a list of available emboss reasons for a given card identified by ShadowCardNumber. The method accepts GetAvailableEmbossReasonListRequest containing ShadowCardNumber. The response returns GetAvailableEmbossReasonListResponse with a list of GetAvailableEmbossReasonByCardStatusResult, each containing EmbossReasonSubCode, EmbossReasonSubDesc, StatusCode, StatusReasonCode, and ProductNumber.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getAvailableEmbossReasonList › Request Body
shadowCardNumberShadow card number whose permitted emboss reasons are listed. The facade does not validate it and passes it straight to the CIS online service.
getAvailableEmbossReasonList › Responses
Success.
The facade adds nothing: it forwards the shadow card number to the CIS online service and re-projects the result. This operation has no validation block, so a blank shadow card number reaches the downstream service unchecked.
The mapping is null-tolerant at every level. If the CIS online service returns no response, or a response with no result list, getAvailableEmbossReasonByCardStatusResult is absent from the reply. A shadow card number that matches nothing therefore comes back as a 200 with no list rather than as a refusal.
Each entry is re-projected onto exactly five fields: embossReasonSubCode, embossReasonSubDesc, productNumber, statusCode and statusReasonCode.
getMccGroupAll
Retrieves all MCC groups from cache using _cache.GetMccGroupAll() and maps them to a list of MccGroup objects containing InstitutionCode, Kk100hOrderNumber, MccGroupCode, MccGroupDescription, QualificationIndicatorCode, UseInApplicationFlag, and ValidFlag.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getMccGroupAll › Responses
Success.
The list is served from the in-process cache, not from the database. It is whatever the parameter service returned at start-up, and refreshCache is what reloads it. No filter is applied here, so invalid groups are included and validFlag has to be read by the caller. If the cache slot was never filled, listOfMccGroup comes back as null rather than as an empty array.
getTrnStatusAll
Retrieves all transaction statuses along with their codes, descriptions, and validity flags for core banking integration.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getTrnStatusAll › Responses
Success.
The list is served from the in-process cache, not from the database. It is whatever the parameter service returned at start-up, and refreshCache is what reloads it. Despite the operation name no valid-flag filter is applied, so invalid statuses are included and validFlag has to be read by the caller. If the cache slot was never filled, listOfTrnStatus comes back as null rather than as an empty array.
getBinDomesticByBin
Service that lists local card information based on the provided BIN.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getBinDomesticByBin › Request Body
binCard BIN. It is right-padded with zeros to twelve digits and then matched numerically against the minimum and maximum of each domestic BIN range, so a shorter prefix is accepted. The value must be numeric.
getBinDomesticByBin › Responses
Success.
The BIN ranges are not read from the database on each call. They are served from the in-process cache, which is filled at start-up from the parameter service, so a range added or changed afterwards is not seen until refreshCache has run. The first range whose minimum and maximum bracket the padded BIN wins; the operation does not look for a closest or longest match. issuerBankCode is returned with its trailing spaces removed.
validFlagWhether the row is live. The platform sets it.
acqFlagbonusFlagbusinessFlagpreAuthDebitFlagbinMinValuebinMaxValuebinDescriptionprocessorBinissuerBankCodecardTypeValues:
C— creditD— debitP— prepaid
cardBrandWhich scheme the card is issued on.
panLengthrewardTypeWhich kind of reward was earned.
authenticationTypeloyaltyProgrambinLengthgetApplicableProducts
Retrieves all applicable card products from cache. Maps each cached product to GetApplicableProductsResponseItem including Bin, Brand, ClassCode, ContactlessAbility, DigitalAbility, EmvAbility, GroupCode, IsNoName, ListOfApplicableChannel, ProductName, ProductNumber, ProductShortName, SegmentCode, TenantId, TypeCode, TypeCodeDetail, and VirtualAbility. Returns the list as GetApplicableProductsResponse.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getApplicableProducts › Request Body
queryDateIgnored — The operation never reads it. The result is the same whatever date is sent, and whether or not the property is present.
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.
getApplicableProducts › Responses
Success.
The whole applicable-product catalogue is served from the service's in-memory cache. Nothing is read from the database on the call, no customer is involved, and no date filtering is applied.
The list reflects the cache as it was last refreshed. A product definition added since then is missing until the cache is refreshed, and if the cache entry has not been loaded at all the response carries no product list rather than an error.
The products the search matched.
getMccDefinitionGroupbyMccMccdescription
Retrieves MCC definition groups by MCC and MCC description from the internal repository using _intRepository.GetMccDefinitionGroupbyMccMccdescription().
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getMccDefinitionGroupbyMccMccdescription › Responses
Success.
The response carries no body. The repository method runs the grouping query with ExecuteNonQuery and returns only an affected-row count, and the facade discards even that, so no MCC row ever reaches the caller. A 200 means the query ran, nothing more.
getNetworkTypeDefByValidFlag
Retrieves all network type definitions with valid flag. Returns a list of objects containing insert and update metadata, valid flag, network type code, and network type description.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getNetworkTypeDefByValidFlag › Responses
Success.
The list is read live from the parameter database on every call, not from the cache, so refreshCache has no effect on it. Only rows whose valid flag is set are returned, and when none are valid NetworkTypeDefList comes back as an empty list rather than as an error. The rows are unordered.
getResponseCodeDefByValidFlag
Retrieves a list of response codes filtered by valid flag. Each item includes transaction domain, response code, description, success flag, and metadata such as insert/update dates and user IDs.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getResponseCodeDefByValidFlag › Responses
Success.
The list is read live from the parameter database on every call, not from the cache, so refreshCache has no effect on it. Only rows whose valid flag is set are returned, and when none are valid ResponseCodeDefList comes back as an empty list rather than as an error. The rows are unordered.
getResponseReasonCodeDefByValidFlag
Retrieves a list of response reason codes filtered by valid flag. Each item includes the reason code, description, local description, validity flag, and metadata such as insert/update dates and user IDs.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getResponseReasonCodeDefByValidFlag › Responses
Success.
The list is read live from the parameter database on every call, not from the cache, so refreshCache has no effect on it. Only rows whose valid flag is set are returned, and when none are valid ResponseReasonCodeDefList comes back as an empty list rather than as an error. The rows are unordered.
getTrnCodeDefByValidFlag
Retrieves all valid transaction codes along with their descriptions, insert/update metadata, and validity flags. This is used to get the list of transaction code definitions for core banking integration.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getTrnCodeDefByValidFlag › Responses
Success.
The list is read live from the parameter database on every call, not from the cache, so refreshCache has no effect on it. Only rows whose valid flag is set are returned, and when none are valid TrnCodeDefList comes back as an empty list rather than as an error. The rows are unordered.
getTrnCodeMatrixByValidFlag
Retrieves all valid transaction code matrices along with their details, flags, and associated metadata. This is used to get the list of transaction code matrices for core banking integration.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getTrnCodeMatrixByValidFlag › Responses
Success.
The list is read live from the parameter database on every call, not from the cache, so refreshCache has no effect on it. Only rows whose valid flag is set are returned, and when none are valid TrnCodeMatrixList comes back as an empty list rather than as an error. The whole matrix is returned; there is no way to ask for one transaction code. The rows are unordered.