Statements and billing
Produce the statement a cardholder reads, and manage the period, delivery preference and address behind it.
getDelinquencyInterestAmount
Retrieves delinquency interest amounts for a given ShadowCardNumber. Accepts GetDelinquencyInterestAmountRequest with ShadowCardNumber. Calls _intRepository.GetDelinquencyInterestAmount() and maps results to ListGetDelinquencyInterestAmountResponse containing ListOfDelinquency with properties such as CurrencyCode, Rate, MainCardRefNumber, DelayAmountWithTax, and DelayType.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getDelinquencyInterestAmount › Request Body
shadowCardNumberShadow card number of the card. No check is applied to it; the value is passed straight to the query, where it is matched against valid card master rows.
getDelinquencyInterestAmount › Responses
Success.
The list is read live from the statement tables, not from a cache. It covers only valid statement headers of the card's main card reference, and only delay details that are valid and of delay type 1 or 2, which are returned as delayType SatışGecikme and NakitGecikme. A shadow card number that matches no card, or one whose card has no statements, returns listOfDelinquency as an empty list rather than an error. Statement headers with no matching delay detail still appear, with rate and delayAmountWithTax at zero.
setStatementDocumentId
Sets or updates statement document IDs for a list of statements. For each statement in the request, it retrieves mailing info based on masked card number and statement date, then either creates a new statement document or updates an existing one. Additionally, if email sending is enabled, it triggers a notification with relevant statement and customer details. The SetStatementDocumentOnly method returns a summary of inserted, updated, and skipped rows.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
setStatementDocumentId › Request Body
ListHasNoItem — The statements to attach document ids to. Must be sent and must hold at least one entry.
setStatementDocumentId › Responses
Success.
Nothing comes back. The operation returns no body, and success does not mean every entry was applied — only that the list was not empty.
Each entry is looked up by masked card number, customer number, statement date and currency together. An entry that matches no statement is skipped without a word: no error, no count, nothing in the response to distinguish it from one that was applied. Use setStatementDocumentOnly when you need to know.
Where the lookup does match, the facade creates a statement document record if the statement has none and overwrites the existing document id if it has one. There is no check that the current document id differs from the one sent.
This operation also emails the cardholder, which is the only thing that separates it from setStatementDocumentOnly. The mail goes out only when the customer's statement e-mail flag is set, is addressed to the customer's default e-mail address, and carries the statement as an attachment only when the customer's sensitive data permission flag is set. The template is chosen from the card product's parameters, and that same permission flag decides which of the two templates is used.
setStatementDocumentOnly
Processes a batch of statement documents and updates the system accordingly. For each statement in the request, it retrieves mailing info based on masked card number and statement date. If no record exists, a new statement document is created; otherwise, the existing document is updated. The method returns a summary including total rows, inserted, updated, and skipped rows.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
setStatementDocumentOnly › Request Body
ListHasNoItem — The statements to attach document ids to. Must be sent and must hold at least one entry.
setStatementDocumentOnly › Responses
Success.
Same work as setStatementDocumentId, with two differences: this one sends no e-mail, and it tells you what happened.
The four counts are the whole answer. totalRowCount is the number of entries sent, insertedRowCount those whose statement had no document record yet, updatedRowCount those whose existing record was overwritten, and noActionRowCount those whose masked card number, customer number, statement date and currency matched no statement. A response of nothing but noActionRowCount is still a success: the operation never fails on an entry it cannot place.
The counts do not say which entries fell into which bucket. Each skipped and each overwritten entry is written to the service log, and that is the only place the detail exists.
An overwrite is unconditional — there is no check that the document id sent differs from the one already stored, so re-sending the same list counts every entry as updated.
totalRowCountinsertedRowCountupdatedRowCountnoActionRowCountgetCardStatementCutoffReport
Retrieves credit card statement cutoff information for a given ShadowCardNumber, MainCardRefNumber, and optional CustomerNumber on a specific InsertDate. Accepts GetCardStatementCutoffRequest with ShadowCardNumber, MainCardRefNumber, CustomerNumber, and InsertDate. Returns GetCardStatementCutoffResponse containing a list of CreditCardStatementCutoffItem objects, each including CardRefNumber, ShadowCardNumber, CustomerNumber, StatementDate, CapitalAmount, PurchaseInterestAmount, CashInterestAmount, PurchaseDueInterestAmount, CashDueInterestAmount, OtherFeeAmount, CardFeeAmount, CashFeeAmount, InterestBsmvAmount, InterestKkdfAmount, FeeBsmvAmount, and CashInstallmentProfitAmount. Uses _intRepository.GetCreditCardStatementCutoffReportByInsertDate internally.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getCardStatementCutoffReport › Request Body
insertDateThe statement date to report on. Compared as a date, so any time component is ignored. Nothing validates it; a date with no cut-off statement returns an empty list.
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 report to one card. Matched exactly.
mainCardRefNumberNarrows the report to one main card reference. Matched exactly.
customerNumberNarrows the report to one customer.
getCardStatementCutoffReport › Responses
Success.
This operation never leaves the facade: it runs a repository view and converts the rows. Nothing is validated and nothing checks that the card, the card reference or the customer exists, so a miss is a success with an empty listOfCardStatementCutoff rather than an error.
All three card criteria are optional in the query as well as in the document, and each one that is left out is simply not applied. A request carrying only insertDate therefore reports every card that has a cut-off statement on that date; there is no paging and no cap on the number of rows.
Only cut-off statements are reported, and only valid ones on main — not supplementary — cards that are current for their card reference. The figures are sums built in the view: each amount adds the current, previous and reversal buckets together, so a row is a total for the statement rather than a single posting.