Platform
How money moves
Cash advance, instalments, statements and repayment — and the fact that decides how you read all four, which is that most of these calls are facades.
Read from the Issuing digital channel services in October 2026, following each operation into the service it delegates to. The delegation itself, the fixed interest period, the tax selection, the transaction-code matrix fallback and the notification condition were all found in code. The behaviour of the services behind the facade — the authorisation path and transaction management — is named here but not documented: those are not APIs this portal publishes.
- Whether the authorisation service's own total and the taxed total computed here are ever expected to agree, and which a bank is meant to display.
- Whether the deferral components left out of the instalment total are an oversight or a deliberate exclusion.
The card side of this platform is a set of services that own their data. The money side mostly is not: the operations you call on a digital channel API carry your request to another service and carry its answer back, with little or no rule of their own.
That is the first thing to know, because it changes how a failure reads.
Most of these calls are facades
Where the work actually happens
| You call | It delegates to |
|---|---|
getCashAdvanceInfo, doCashAdvance |
the online authorisation service |
manuelInstallmentOrder, its simulation |
transaction management |
doCreditCardDebtPayment |
transaction management |
| Statement reads | the card's own repositories |
So when a cash advance is refused, the refusal originated behind the operation you called. The code and the wording belong to that service, and the first question in a support thread is which one. The facade's own contribution is usually one of two things: turning an unsuccessful answer into a business failure, or computing something the service behind it does not.
Cash advance: two calls, and two totals
The enquiry writes nothing. It asks the authorisation service for the fee and the interest rate, then computes the taxed total here — and that is the part worth reading closely:
- Interest is
amount × rate × period ÷ (30 × 100), and the period is fixed at 30 days. It is not the term of anything; it is the assumption the preview is built on. - Two legal taxes are added, and which rates apply is chosen by whether the card's product segment marks it commercial.
- The result is a second total, beside the one the authorisation service returned. They are not the same number, and both come back. Which one your screen shows is a product decision somebody has to make deliberately.
The quiet failure
If the card cannot be read, the tax computation is skipped and the fields come back as zeros — no error is raised. "This costs nothing" and "no such card" look identical. Confirm the card before trusting a free quote. The withdrawal itself has no such silence: a refusal is raised as a business failure.
Instalments: the transaction is what gets split
The key is the transaction's own id. The card number only says which card that transaction belongs to. So the order is: find the transaction, simulate a plan for it, then order the plan.
Two things in the simulation do not say what they appear to:
- The instalment count in the response is copied from your request, not taken from the service's answer. If the service settles on a different number, the field will not tell you — the length of the schedule it returns will.
- The headline total leaves out the deferral taxes. It adds interest, the two legal taxes and the instalment fee; the three deferral components are not in it. Ask for a deferral month and the total you display is short.
Ordering a plan returns a record id and nothing else. Instalments do not become debt at once — one falls onto each statement, and the ones that have not reached a statement yet are read separately, grouped by the statement date they are waiting for.
Statements belong to the main card
A supplementary card's own reference will not fetch a statement; its spending appears as rows on the main card's. Two further rules decide whether anything comes back at all:
- With no date given, the window opens at the first of the month seven months back. Give a single statement date and the window is not applied — that is how an older period is reached.
- Where the current table holds no row, the read falls back to a history table. If both are empty the totals stay at zero and the response is still a 200.
Totals and rows are separate reads, so rows can come back while the totals stay at zero. Neither confirms the other.
Repayment is more parametric than it looks
Which transaction code a payment is written under is not a field you set. It is resolved from a channel payment matrix in four steps, and a value the service does not recognise does not fail — it falls through to the next one:
- A resource code of
0,1,2or3selects the row for that code. - Anything else: the row whose resource code is empty.
- No such row: the channel's first row.
- No rows at all: a built-in default.
The channel is left-padded with zeros to three characters before it is matched,
so 1 is looked up as 001. Send the code as the catalogue spells it and this
never arises.
The notification is narrower than it looks
A payment SMS is sent only when the channel is the batch channel. On every other channel the notification call is not made at all — a condition in the code, not a missing configuration. Even there it is wrapped: a failed send is logged and the payment stands. A missing SMS never means a missing payment.
One pattern across all of it
Four of the operations on this side return 200 and may have changed nothing: the two that take rows of operation limits, the one that saves card permissions, and the cash advance enquiry that answers with zeros. In every case the thing to read is not the status code but the result inside the response.