Transactions
Read what happened on a card and correct it — transaction history, pending provisions, reversals and slip receipts.
getCreditTransactionList
Retrieves a list of credit card transactions for a given shadow card number. Accepts GetCreditTransactionListRequest containing ShadowCardNumber, EmbossName, SourceNetwork, TrnCodeMatrixId, MaxAmount, MinAmount, Transactiondatebegin, Transactiondateend, and TrnCode. Returns GetCreditTransactionListResponse with a list of CreditTransactionList items. Each item contains transaction details including AcqRefNumber, AuthorizationNumber, BillingAmount, BillingCurrency, Merchant details, Card details, transaction amounts, dates, log/status codes, installment info, and rewards. Validates Transactiondatebegin, Transactiondateend, and ShadowCardNumber before calling _crdTransactionServiceProxy.GetCreditTransactionList().
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCreditTransactionList › Request Body
shadowCardNumberThe card whose transactions are listed. The document leaves this optional; the facade does not, and refuses a request without it.
transactiondatebeginStart of the transaction date range.
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.
transactiondateendEnd of the transaction date range.
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.
embossNameNarrows the list to transactions on a card carrying this emboss name.
Declared at 26 on the card master and 30 on the customer asset, so no single width is published. nameOnCard, which the services truncate to 26 before writing, is the field to send a name on.
maxAmountUpper bound on the transaction amount.
minAmountLower bound on the transaction amount.
sourceNetworkNarrows the list to one acquiring network.
trnCodeMatrixIdNarrows the list to one transaction code matrix entry.
trnCodeNarrows the list to one transaction code.
getCreditTransactionList › Responses
Success.
The facade checks only that the two dates and the card number are present. It does not check that the begin date falls before the end date, does not cap the width of the range, and does not check that the card exists; the credit transaction service behind it decides all of that.
Every other field is passed through untouched and unvalidated. The request the facade builds also carries a customer number, but the line that would fill it is commented out, so a caller cannot narrow the list by customer through this operation.
A card with no matching transactions comes back as a success with no creditTransaction array rather than as an error.
getPaymentAndCashadvanceInformationByCriterias
Retrieves payment and cash advance information filtered by various criteria including shadow card number, date range, customer number, channel type, branch, and transaction code. Returns a list of transactions with details such as masked card number, payment date, transaction amount, transaction code, currency, description, status, provision number, product transaction reference, channel information, and status description.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getPaymentAndCashadvanceInformationByCriterias › Request Body
channelTypeNarrows the list to one channel.
customerNumberNarrows the list to one customer.
beginDateStart of the payment date range.
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.
endDateEnd of the payment date range.
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.
shadowCardNumberNarrows the list to one card.
trnCodeMatrixApplied by the facade after the service has answered, not by the service. Only 06, 08 and CASHADVANCE select anything; leaving it out returns every row. Any other value returns an empty list.
The matrix itself rather than the identifier of a row in it; no column behind it.
branchNoNarrows the list to one branch.
getPaymentAndCashadvanceInformationByCriterias › Responses
Success.
The facade validates nothing at all here. Both dates, the card, the customer, the channel and the branch go straight to the credit transaction service, which decides whether the range is acceptable and whether the card and customer exist.
trnCodeMatrix is different: the service never sees it. The facade fetches the whole answer and then filters it in memory against a fixed list of three values. 06 and 08 are matched against each row's transaction code, while CASHADVANCE is matched against its transaction code matrix id. A value outside that list is not rejected — it simply matches nothing, and the operation returns a success with an empty list.
The filter is applied after the service has already built the full result, so narrowing by trnCodeMatrix does not make the call cheaper.
getAuthorizationListByBegindateEnddate
Retrieves a list of authorization transactions based on the provided date range and optional filters. The method accepts GetAuthorizationListByBegindateEnddateRequest containing GetAuthorizationListByBegindateEnddateParam, which allows filtering by AuthStatus, BeginDate, EndDate, MaxAmount, MinAmount, NetworkType, ResponseCode, ResponseReasonCode, ShadowCardNumber, and TrnCodeMatrixId. The response returns GetAuthorizationListByBegindateEnddateResponse containing a list of GetAuthorizationListByBegindateEnddateResult items, including details such as AuthorizationNumber, CardRefNumber, CustomerNumber, ShadowCardNumber, TransactionDate, TrnAmount, TrnCurrencyDescription, TrnStatusDescription, MerchantName, MerchantCountryCode, ChannelTypeDescription, TerminalNumber, and other authorization-related metadata.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getAuthorizationListByBegindateEnddate › Request Body
The search criteria. The repository throws when this is missing, so it must be sent.
getAuthorizationListByBegindateEnddate › Responses
Success.
This operation never leaves the facade: it passes the criteria straight into a repository view and returns the rows. Nothing is validated, and there is no check that the card exists — an unknown card is a success with an empty result, not an error. There is no ordering check between the two dates, no maximum range and no cap on the number of rows.
The view is the union of three sources: authorisations, the daily debit transaction pool and non-financial authorisations. An authorisation that has already reached the daily pool is excluded from the first and third sources so it is reported once. Only cards flagged as the current card for their card reference are considered. Rows are ordered by transaction date descending across the whole union.
getDbttransactionByCardrefCustomernum
Retrieves DBT transactions for a given card reference or customer number. Accepts GetDbttransactionByCardrefCustomernumRequest with GetDbttransactionByCardrefCustomernumParam containing filters such as CustomerNumber, MainCardRefNumber, CardSeqNumber, TransactionDateBegin, TransactionDateEnd, MCC, RRN, TRN_STATUS, TRN_CODE_MATRIX_ID, ResponseCode, NetworkType, AuthorizationMatchStatus, MinAmount, MaxAmount, EmbossName, SourceNetwork. Returns GetDbttransactionByCardrefCustomernumResponse containing a list of GetDbttransactionByCardrefCustomernumResult items. Each result item includes transaction details such as PAN_ENTRY_MODE, MASKED_CARD_NUMBER, MAIN_CARD_REF_NUMBER, CUSTOMER_NUMBER, MAIN_CUSTOMER_NUMBER, PRODUCT, CHANNEL_TYPE_DESCRIPTION, NETWORK_DESCRIPTION, TERMINAL_TYPE, SETTLEMENT_AMOUNT, SETTLEMENT_CURRENCY, CLEARING_NUMBER, CLEARING_CHANNEL, CLEARING_DATE, TRN_CODE_MATRIX_DESC, TRN_AMOUNT, TRN_CURRENCY, LOCAL_AMOUNT, LOCAL_CURRENCY, TRN_DATE, EARNED_REWARD_MERCHANT, EARNED_REWARD_BANK, REWARD_TYPE_DESCRIPTION, MCC_DESCRIPTION, AUTHORIZATION_NUMBER, TERMINAL_NUMBER, MERCHANT_NAME, MERCHANT_CITY, MERCHANT_COUNTRY_CODE, BKM_UNIQUE_MERCHANT_ID, MERCHANT_AMEX_ID, INVOICE_NUMBER, DISPLAY_AT_CHANNELS, TRN_DESCRIPTION, EOD_DATE, TRN_ORIGIN, ACQ_REF_NUMBER, CAMPAIGN_CODE_ACQ, CAMPAIGN_CODE_ISS, EARNED_REWARD_CAMPAIGN_ISS, EARNED_REWARD_CAMPAIGN_ACQ, REF_UTID, UTID, REQUEST_DATE, OFFLINE_FLAG, EMBOSS_NAME, CARD_SEQ_NUMBER, AUTHORIZATION_MATCH_STATUS, CURRENCY_CODE_DESCRIPTION, MATCH_STATUS_DESCRIPTION, RRN, TRN_STATUS_DESCRIPTION, BILLING_AMOUNT, BILLING_CURRENCY, PIN_USAGE, IS_CHIP_FLAG. Calls _intRepository.GetDbttransactionByCardrefCustomernum() and maps results to internal structure.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getDbttransactionByCardrefCustomernum › Request Body
The search criteria. The operation dereferences this without a null check, so it must be sent.
getDbttransactionByCardrefCustomernum › Responses
Success.
This operation never leaves the facade: it passes the criteria straight into a repository view of cleared debit transactions and returns the rows. There is no validation of any kind, and no check that the card, the card reference or the customer exists — a criterion that matches nothing is a success with an empty result.
Every criterion is optional in the query as well as in the document, and they are combined with AND. A request whose criteria are all empty is therefore not rejected: it returns every current cleared debit transaction the platform holds. There is no paging and no cap on the number of rows.
Only cards flagged as the current card for their card reference are considered. Rows are ordered by transaction date descending.