Schemas

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The last four digits of the card, which pick which of the customer's cards is activated. Matched against the end of the masked card number rather than a stored field of its own, and no length is checked: a shorter value matches more than one card and the operation refuses rather than choosing, while anything longer than the masked number matches nothing.

The delivery barcode the consignment is tracked by.

Not read by the service. activateNoNameCard matches the card on customerNumber and lastFourDigit alone — the facade forwards this field and ActivateNoNameCard does not mention it, on credit, debit or prepaid. It is accepted and ignored.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required — Case the documents are attached to. The contract holds a non-nullable integer, so leaving the field out sends 0.

The case identifier in the external dispute system. Only the integration route reads it; the local route attaches by CaseNumber alone.

The document identifier in the external dispute system. Only the integration route reads it.

Documents to attach. Only the identifier of each entry is forwarded, and a null entry in the array is forwarded as a reference with no identifier rather than skipped.

Which group of products this one belongs to.

Demanded and then not read. The service refuses the request when this is absent and never consults it afterwards — the control it runs is about the main customer, not about a product group. Send any group code the column accepts; it does not narrow what is checked and it does not appear in the answer.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The account being linked to the card. It must exist, belong to the card's customer, and be neither shared nor a foreign-currency account — each is its own refusal.

The foreign-currency code of the account, where the card draws on one.

The branch that holds the account, as core banking numbers it.

Values:

• A — main account
• V — virement

The suffix that distinguishes one account from another under the same number at core banking.

Required in practice — The card the operation acts on. Not validated as a field — a request that names no card, or names one that does not exist, is refused as a business failure with no card found rather than as a missing field.

A name for the account, shown to the cardholder where the account is listed. The platform stores it and does not interpret it.

The account's IBAN, stored alongside the account number.

Not read when sent. Attaching an account has the line commented out, and card creation writes false whatever is sent. The account listings return the stored value.

The identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Shadow card number of the card whose pending emboss request is cancelled. Checked by the facade and checked again by the issuing service, with the same rule on both sides.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Transaction id of the early-release payment being reversed.

Amount of the original early-release payment.

Currency of the original payment.

Same client reference used on the payment call.

UTID of the cash-installment plan the payment belonged to.

The installment's own transaction identifier, carried through to the services that hold it.

Card reference when needed to locate the original payment.

Main customer number when required by the cancel criteria.

Original transaction date when the cancel needs date scoping.

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.

The platform's identifier for the transaction row.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Transaction id of the debt payment being reversed.

Amount of the original payment.

Currency of the original payment.

Same client reference used on doCreditCardDebtPayment.

Card reference when cancelling by card rather than shadow alone.

Main customer number when required by the cancel criteria.

Original transaction date when the cancel needs date scoping.

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.

The platform's identifier for the transaction row.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required — Case being withdrawn. The contract holds a non-nullable integer, so leaving the field out sends 0, and the local route refuses that.

Dispute transaction within the case that is being withdrawn. Either this or UTID identifies the line: the local route matches on DISPUTE_TRANSACTION_ID = :id OR UTID = :utid and refuses the request only when both are absent. The contract holds a non-nullable integer, so leaving it out sends 0.

Unique transaction identifier of the disputed transaction, as an alternative to DisputeTransactionId.

Free-text reason for the withdrawal, written to the case history. It is truncated rather than refused: the local route stores SUBSTR(:CUSTOMER_EXPLANATION, 1, 200), so anything past 200 characters is dropped silently.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

The identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

Why the application is being cancelled.

Free text alongside the cancellation reason.

The foreign-currency code of the account, where the card draws on one.

The branch that holds the account, as core banking numbers it.

The suffix that distinguishes one account from another under the same number at core banking.

The account at the bank's core banking system that the card draws on. It must already exist, belong to the card's customer, and be neither shared nor a foreign-currency account.

The identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.

Whether the row is live. The platform sets it; a value sent here is replaced.

When the row was created.

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.

Values:

• A — main account
• V — virement

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

A name for the account, shown to the cardholder where the account is listed. The platform stores it and does not interpret it.

An audit column the platform fills in. It is on the request because the contract was generated from the table, and a value sent here is replaced.

When the row was last changed.

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.

An audit column the platform fills in. It is on the request because the contract was generated from the table, and a value sent here is replaced.

An audit column the platform fills in. It is on the request because the contract was generated from the table, and a value sent here is replaced.

An audit column the platform fills in. It is on the request because the contract was generated from the table, and a value sent here is replaced.

The account's IBAN, stored alongside the account number.

Not read when sent. Attaching an account has the line commented out, and card creation writes false whatever is sent. The account listings return the stored value.

The currency of the amount, as its three-letter code.

The account at the bank's core banking system that the card draws on. It must already exist, belong to the card's customer, and be neither shared nor a foreign-currency account.

The branch that holds the account, as core banking numbers it.

The foreign-currency code of the account, where the card draws on one.

The balance available to spend.

Values:

• A — main account
• V — virement

Not read when sent. Attaching an account has the line commented out, and card creation writes false whatever is sent. The account listings return the stored value.

The currency of the amount, as its three-letter code.

The error in words. errorCode is the part to match on.

The main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

What kind of payment this is.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.

How much of the limit is left.

The card's own spending limit.

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.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

The description of cardStatusCode, carried alongside it for display. It is not a key: match on the code.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

Values:

• 1 — corporate
• 2 — individual
• 3 — employee
• 4 — sole proprietorship

Not set is N.

The description of customerType, carried alongside it for display. It is not a key: match on the code.

How many periods the account has been in arrears.

The description of delinquencyStatusCode, carried alongside it for display. It is not a key: match on the code.

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.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.

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.

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.

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.

The card product's full name.

The card product the card is issued on. Defined in the parameter tables; getCardProductList returns the ones a tenant may use.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

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.

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.

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.

The least that may be paid against the statement.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Which tenant's records to read. Omitting it reads the rows that belong to no tenant rather than all of them.

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.

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.

What is left of the statement's debt.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Whether the card draws against the customer's limit rather than having one of its own.

Which profile the card's limits come from.

The description of profileCode, carried alongside it for display. It is not a key: match on the code.

Which limit row this is: the transaction group, the network and the channel together identify one. The descriptions beside each code are returned for display and are not part of the key.

The most the card may spend in one transaction.

The same cap as a share of the card's limit rather than an amount.

The most transactions the card may make in a day.

The most the card may spend in a day.

The most transactions the card may make in a week.

The most the card may spend in a week.

The most transactions the card may make in a month.

The most the card may spend in a month.

The most transactions the card may make in a year.

The most the card may spend in a year.

The amount.

Which group of merchant categories the merchant falls in.

The currency of the amount, as its three-letter code.

Which group of merchant categories the merchant falls in.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Values:

• DS — digital slip — whether the cardholder's slip is printed
• DC — dynamic CVV — whether the card's CVV is generated per period

Values:

• HardCopy — a printed slip — the value DS takes
• DigitalSlip — a digital slip — the value DS takes
• true — dynamic CVV on — the value DC takes, compared as this exact string

The amount.

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.

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.

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.

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.

The currency of the amount, as its three-letter code.

Which instalment this is.

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.

What each instalment comes to.

The capital part of the instalment, without interest.

The interest charged across the instalments.

Whether the transaction has reached a statement.

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.

The amount of the transaction.

How many instalments to split the amount across. The available counts for a card and amount come from the simulation operations.

What the instalments come to together.

How many instalments are still to run.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The unique transaction identifier the platform gives a transaction, and the handle every later operation on it takes. Returned by the transaction listings.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card being closed and replaced. One call does both, so this is the card the status change lands on and the card the replacement is issued against.

How the replacement card is issued. The object itself is required, and two of its fields are checked with it.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

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.

Whether the card ends this operation in an active status.

The cards the operation closed.

What the replacement produced.

Why the card is being replaced. It decides what the replacement inherits and whether the card number changes.

Whether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

What the replacement card should carry — delivery, address and emboss details. Left out, the replacement inherits the card's own.

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.

Whether the card ends this operation in an active status.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Whether the change produced a new card.

Whether the change moved the card to another product.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required in practice — The card the operation acts on. Not validated as a field — a request that names no card, or names one that does not exist, is refused as a business failure with no card found rather than as a missing field.

Whether the card takes part in automatic limit increases.

Required in practice — The card the operation acts on. Not validated as a field — a request that names no card, or names one that does not exist, is refused as a business failure with no card found rather than as a missing field.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Whether the card takes part in automatic limit increases.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The branch to move the card or customer to.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

The branch before the move.

The branch after it.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The limit the card is lowered to — an absolute figure, not a difference.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

The limit as a share of another limit rather than an amount.

How much of the card's limit may be drawn as cash, as a share.

Whether the customer's limit moves with the card's.

Which profile set the card's limits come from. Defined in the parameter tables.

The credit application the limit notification is filed under. It is forwarded to core banking, which files the notification and answers; the platform stores nothing of what is sent, so its format is the bank's rather than this API's.

Only read when the customer's limit is being lowered too, and then only for an individual product: the notification step runs under changeCustomerLimit, and a corporate product never reaches it.

Leaving it out is not the same as having none. The service falls back to the application id of the customer's current card — a supplementary one first — and files the notification under that, so omitting the field chooses a value rather than omitting one.

Whether to leave the payment in place when the core banking leg fails rather than reversing it.

The limit changes to reverse, by the log id each change returned.

The customer limit changes to reverse, by the log id each change returned.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The limit the card is raised to — an absolute figure, not a difference. A value equal to or below the card's current limit is refused by the increase rules rather than accepted as a no-op.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

The limit as a share of another limit rather than an amount.

How much of the card's limit may be drawn as cash, as a share.

Whether the customer's limit moves with the card's.

Which profile set the card's limits come from. Defined in the parameter tables.

The limit changes to reverse, by the log id each change returned.

The customer limit changes to reverse, by the log id each change returned.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

ListHasNoItem — The card limit changes to undo. Each entry is one cardLimitChangeLogId — a whole number, the record id of a row in the card limit change log — and they are the ids changeCardLimitDecrease, changeCardLimitIncrease and the other limit changes hand back in their own listOfCardLimitChangeLogId. A caller does not compose one.

Mandatory: an absent list and an empty one are refused alike. An id that matches no log row stops the whole request rather than being skipped.

The customer limit changes to undo, in the same form: each entry is the record id of a row in the customer limit change log, as returned in listOfCustomerLimitChangeLogId. Left out or empty, no customer limit is touched and only the card limits above are reversed. An id that matches no log row stops the request.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Values:

• DS — digital slip — whether the cardholder's slip is printed
• DC — dynamic CVV — whether the card's CVV is generated per period

Values:

• HardCopy — a printed slip — the value DS takes
• DigitalSlip — a digital slip — the value DS takes
• true — dynamic CVV on — the value DC takes, compared as this exact string

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

Whether every main card of the customer is included.

Whether every card of the customer is included.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

Checked against the platform's Pin parameter rather than a fixed length, so it follows the tenant's configuration and can change without a release.

Checked against the platform's Pin parameter rather than a fixed length, so it follows the tenant's configuration and can change without a release.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

Whether the value presented matched the one held.

The PIN block as the key management service produced it. The PIN itself never travels.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card whose status changes.

The status to move to. Must be a status the platform defines.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Dependent — The reason for the new status. Must be a reason defined for cardStatusCode.

The caller's own id. Echoed back in the error body.

Default false — Reissue the card with the status change.

The date the closure was requested.

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.

Default false — Change only this card, not the cards that would follow it.

Whether the card ends this operation in an active status.

The cards the operation closed.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The limit to set.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The limit as a share of another limit rather than an amount.

How much of the card's limit may be drawn as cash, as a share.

Whether the customer's limit moves with the card's.

Which profile set the card's limits come from. Defined in the parameter tables.

Not read by the service. The credit application a limit notification would be filed under, which this operation never files: the notification runs only for an individual product and this one refuses anything that is not corporate. The facade forwards the field and nothing behind it looks at it.

changeCardLimitDecrease is where it is read.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The limit the card is raised to — an absolute figure, not a difference. This is the one field the facade checks itself: an absent value is refused with 60008 before the limit service is reached.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

One-of — The card whose limit changes — send this or the other card identifier. Neither is validated as a field. The service's checks on them are commented out, so a request carrying neither is refused as a business failure with no card found, rather than as a missing field.

The limit as a share of another limit rather than an amount.

How much of the card's limit may be drawn as cash, as a share.

Default false — Raise the company's limit along with the card's. True returns a second list of log ids, listOfCustomerLimitChangeLogId; false leaves it empty and the card limit may then not exceed the company's.

The profile set the raised limit is applied under. Forwarded to the limit service, which decides what it means; nothing in this API reads it.

The limit changes to reverse, by the log id each change returned.

The customer limit changes to reverse, by the log id each change returned.

Which statement period the card is billed on. The periods a product allows come from the reference data.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

Whether the statement is sent by e-mail.

Whether the statement is posted on paper.

Whether the statement is announced by SMS.

Which kind of address the statement is posted to.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The branch to move the card or customer to.

The branch before the move.

The branch after it.

How many cards the operation changed.

The cards the operation acted on.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Customer whose cards are moved. Rejected by the facade when absent, and by the service again when zero.

Values:

• A — valid
• B — pending
• C — stolen
• D — cancelled by the bank
• F — fraud
• G — temporarily blocked
• I — cancelled
• L — lost
• M — cancelled by the customer
• T — corporate dummy

Why the status is being set. The valid reasons depend on the status: getAvailableCardStatusList returns the pairs a card may move to.

Whether to activate the card as it is created.

The cards the operation closed.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The customer at the bank's core banking system, as a number. The platform stores it rather than issuing it, so it comes from the core.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The limit to set on the customer.

The limit to set on the card.

Whether the increase applies to every main card of the customer.

The limit changes to reverse, by the log id each change returned.

The customer limit changes to reverse, by the log id each change returned.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

The card the operation acts on, by its shadow card number — the platform's own reference, not the PAN.

The encrypted PIN block holding the cardholder's current PIN.

Its size follows the block format and the key it was built with rather than a column.

The encrypted PIN block holding the PIN being set.

Its size follows the block format and the key it was built with rather than a column.

The date the current PIN block was produced under. It belongs with currentEPB — the pair is what the key management service verifies.

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.

The date the new PIN block was produced under, paired with newEPB the same way.

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.

Whether the operation did what it was asked to. A false here arrives with HTTP 200, so it has to be read rather than inferred from the status.

The PIN block as the key management service produced it. The PIN itself never travels.

The downstream system's own result code, passed through. 00 and 0 are success; anything else is its refusal, and responseReasonCode or the description says which.

The description of responseCode, carried alongside it for display. It is not a key: match on the code.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Required in practice — The virtual card whose limit is set. Not validated here — the facade forwards every field untouched, so an absent or unknown value is refused by the limit service in its own vocabulary. The card's product must be a virtual one; this operation is not a general limit change.

Required in practice — Whether the limit expires. A fixed limit is time-boxed and makes endOfDayFlag meaningful; anything else is open-ended. Not validated here, and the limit service refuses a value meaning none.

Values:

• S — fixed — the limit stays as set
• H — decreasing — each transaction reduces it

Not set is N.

Required in practice — The available limit to set. Bounded by three pools at once — the related card's available limit, the main card's and the customer's — and exceeding any one of the three refuses the request. Not validated here.

Conditional — When a fixed limit ends: at the end of the day, or otherwise on the related card's next statement date. This is what makes a single-use card possible. Read only for a fixed limit.

The limit changes to reverse, by the log id each change returned.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Clear PAN used to resolve BIN and card type. Missing or ineligible PANs return soft errors in the 200 body (99000–99002), not HTTP 400.

A card number is not stored by these services; the platform keeps a shadow card number instead.

The outcome, as the downstream system words it.

The platform's own code for the error, and what to match on.

The card the operation is answering about.

Values:

• DS — digital slip — whether the cardholder's slip is printed
• DC — dynamic CVV — whether the card's CVV is generated per period

Values:

• HardCopy — a printed slip — the value DS takes
• DigitalSlip — a digital slip — the value DS takes
• true — dynamic CVV on — the value DC takes, compared as this exact string

Whether the card may be used online.

Whether the card may be used for mail and telephone order.

Whether the card may be used abroad.

Three-digit code identifying the channel on behalf of which the request is made (e.g. 002 for Internet). Mandatory in every request. Used for entitlement checks, limit enforcement and audit logging. Channel codes are managed through configuration parameters and may change over time. Refer to the Channels page for the current list of valid codes.

Product the corporate card is issued on. Rejected when absent and when it matches no card product. Its segment must then be Corporate: an individual product is refused on this field, although the message that comes back reads Product Not Individual, which is the service's own copy of the individual operation's wording. A product that issues virtual cards is refused outright — this operation does not create them. Unlike the individual operations, nothing here consults the applicable-product list.

Customer the card belongs to. Rejected when absent, when zero, and when the number has no personal-information record.

The main card's shadow number. Its master must carry a main customer, that customer's firm information, a limit and a financial record; each missing one is its own refusal.

Branch the application is made at. Rejected when absent and again when it matches no branch.

Ask for the card to be issued as digital. Refused when the product has no digital card ability.

The name embossed on the card. The services truncate to 26 characters before writing rather than refusing a longer one, so a name that matters should be checked at 26.

The second embossed line, used for the company name on a corporate card.

Values:

• P — by post
• S — to the branch

Not set is "".

Which address the card is sent to. Only checked when supplied, and then it may not resolve to None.

Values:

• RA — home
• AL — business
• EA — employer
• OO — alternative
• WA — previous
• SW — SWIFT
• SS — SWIFT name and address
• MR — Mernis, registered
• MS — Mernis, stated

Not set is --.

Which of the customer's addresses to send the card to. The identifier of an address already held for that customer, not an address.

Conditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is the branch delivery type, and the branch it names must then exist. Not read otherwise.

Whether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either way.

What the card may do: e-commerce, international purchases and mail order. Each is optional, and one left unset takes the platform's own default rather than being refused — for e-commerce that default follows digitalCardFlag.

The accounts to attach to the card as it is created. Each entry carries the account's own identifiers; attaching one later is attachCardAccount.

Which cardholder contract the customer accepted. The pair with contractVersionNumber records what was agreed to and when.

Which version of that contract the customer accepted.

The spending limit to open the card with.

Whether an SMS is sent for each authorisation on the card.

The amount an authorisation has to reach before that SMS is sent.

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

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.

The contract record in the application system that this card comes from.

The identifier of the row the operation created or acted on. Returned rather than sent in most operations that carry it.

The card number with its middle digits masked, as the platform stores it. It is a display form, not a key: operations take the shadow number.

The platform's own handle for a card, and the identifier most operations take. It is returned by every operation that creates a card and by the card listings; a caller does not compose one.

The card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.

The card reference of the main card. On a supplementary card this is the card it hangs from; on a main card it is the card's own reference.

What the operation wants to say about work it did anyway. A warning does not mean the operation failed.

The card number, expiry and verification value, returned only where the operation and the channel are entitled to them.

Amount disputed for this transaction. The contract holds a non-nullable number, so leaving the field out sends 0.

Required in practice — Unique transaction identifier of the transaction being disputed, and the only thing the local route matches a transaction on: it refuses the case with TransactionNotFound when no transaction carries this identifier.

Currency of the disputed amount. Used only when DisputeAmountCurrencyCode is absent — the two are read as DisputeAmountCurrencyCode ?? CurrencyCode — and the integration route ignores it entirely, so prefer the other field.