Statements and billing

Produce the statement a cardholder reads, and manage the period, delivery preference and address behind it.

Operations24DomainBilling and statementsStatedocumentedAPIs3

Where this is used

Implemented on 2 programmes. A capability is one business idea, built once per card programme, so these are the programmes it applies to.

Journeys that walk through it

Guides about it

  • Accounting and ReconciliationComprehensive accounting integration with automated journal entries, balance reconciliation, and financial reporting for card operations.
  • End of Day (EOD)Automated end-of-day processing with batch operations, interest calculation, statement generation, and daily reconciliation.

How this behaves

A statement belongs to the main card

The main card's reference is required; a supplementary card's own reference will not fetch one. A supplementary card's spending appears as rows on the main card's statement.

Send the statement date, whatever the schema says.

On the detail read the date is marked nullable and is not treated as optional: the totals are fetched with it before the branch for an absent one can take effect, so a request without it does not succeed. The seven-month window below narrows the rows; it does not stand in for the date.

Two things decide whether a statement comes back

What happens
No minimum givenThe rows reach back to the first of the month seven months back. Older periods are outside it.
A statement date givenThe minimum is not applied at all — that is how an older statement is reached.
Current table emptyThe read falls back to the history table, where older statements are moved.
Both emptyTotals stay at zero and the response is still a 200.
Totals and rows are separate reads.

Rows can come back while the totals stay at zero. They are fetched independently, so neither confirms the other.

The channel changes which rows come back.

Beyond stamping the read, the channel is matched against one channel in the catalogue for which reward transactions are removed from the detail. Independently of the channel, instalment rows in one transaction group are removed unless they are cash-instalment early releases. The same statement read on two channels is not guaranteed to carry the same rows, and this is a condition in the code rather than a configuration.

Operations

credit-digital-channels-integration

POST

/credit/api/getCardStatementSummary

Retrieves summary information for a specific statement.

POST

/credit/api/getCardStatementDetail

Retrieves detailed line items for a specific statement.

POST

/credit/api/getCreditCardStatementSendPreference

Retrieves customer's statement delivery preferences (email, SMS, postal mail).

POST

/credit/api/getCardStatementList

Retrieves list of statements (billing cycles) for a card.

POST

/credit/api/getCreditCardLastStatement

Retrieves the most recent statement information.

POST

/credit/api/getCreditCardLastStatementNew

Retrieves the most recent credit card statement information using ShadowCardNumber and channel. Validates card identifiers, resolves the main card reference number, and fetches the latest statement summary. Returns existing reward points, detailed last statement data, and a list of recent statement summaries ordered by statement period.

POST

/credit/api/getCardStatementDetailSummary

Combines statement summary and detail in a single call.

POST

/credit/api/getCardStatementDetailSummaryNew

Retrieves a summary of credit card statement details including transaction rows, total amounts, minimum payments, remaining debt, earned points, due dates, and currency information. Uses GetCardStatementDetail or GetCardStatementDetailNew internally and maps results to GetCardStatementDetailSummaryResponse objects.

POST

/credit/api/changeCreditCardStatementPeriod

Changes the statement period (billing cycle) for a card.

POST

/credit/api/getStatementPeriodChangeCount

Retrieves count of statement period changes allowed or remaining.

POST

/credit/api/getCalculatedStatementPeriod

Calculates what the statement period would be based on parameters.

POST

/credit/api/getStatementPeriodByProductNumber

Retrieves available statement periods for a product.

POST

/credit/api/changeCreditCardStatementSendPreference

Updates statement delivery preferences.

POST

/credit/api/getCardStatementAddressInformation

Retrieves statement delivery preferences for a credit card based on MainCardRefNumber. Includes flags for statement posting, email, and SMS delivery. Fetches CardMaster and CustomerMaster data.

POST

/credit/api/getCardFinancialInfoByCardRefNumber

Retrieves financial information for a card by card reference number.

POST

/credit/api/getStatementPeriodChangeInfo

Retrieves detailed information about statement period changes for a specific credit card. The service validates the CardRefNumber, fetches the card master record, and then retrieves statement change info from the repository. The response includes the current StatementDate, the next two statement dates (Next1StatementDate, Next2StatementDate), the LastChangeDate, the remaining allowed yearly statement changes (YearlyRemainingStatementChangeCount), and a flag indicating whether a statement period change is currently available (IsStatementPeriodChangeAvailable).

integration-corebanking-outdoor · not published

POST

/Outdoor/api/getCreditCardBalanceInstitution

Reports a credit card's balance to core banking

POST

/Outdoor/api/getCreditCardCurperListInstitution

Reports a credit card's current-period transaction list to core banking

POST

/Outdoor/api/getCreditCardInformationInstitution

Reports a credit card's details to core banking as the institution asks for them

POST

/Outdoor/api/getCreditCardStatementInformationInstitution

Reports a credit card's statement details to core banking