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.

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.

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.

Which kind of log entry is written. The only other field the service demands — the card identifiers are read but not checked, so naming a card that does not exist is a business failure rather than a field one.

The detail recorded against the card log entry.

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 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 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.

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

The value before the change, as recorded in the log.

The value after the change, as recorded in the log.

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.

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.

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.

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.

What the account is to the card. A type other than main or virement takes a further check that the plain types do not.

Values:

• A — main account
• V — virement

The account being linked. Absent and zero are refused separately — zero is checked against the numeric default rather than treated as a missing value.

The card the account is linked to.

The account's currency. Demanded here where credit's equivalent operation does not ask for it at all.

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.

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.

Whether this account is the one drawn on first. The account listings return the stored value.

Whether a transaction in another currency is converted against this account automatically.

Where the account sits in the card's order, which decides what is drawn on first.

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.

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.

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 caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

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.

Where the account sits in the card's order, which decides what is drawn on first.

Whether a transaction in another currency is converted against this account automatically.

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.

Whether this account is the one drawn on first. The account listings return the stored value.

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

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

Whether this account is the one drawn on first. 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 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 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

Whether the card may be used online.

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

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 demanded; unlike credit's equivalent, none of its fields is checked here.

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.

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.

The card being moved to another branch.

The branch the card is moved to. There is no current-branch field on this operation — the card's branch is read rather than asserted.

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.

Which miscellaneous option is being set. The type and its value are checked together and both must resolve against the option definitions.

Values:

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

The value the option is set to, checked against the values its type allows.

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 the change applies to. Not validated — the service's checks on this field are commented out, so a zero or absent value is not refused here.

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, and the move must be permitted for this channel group.

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 statusCode.

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

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.

Whether the card ends this operation in an active 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 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.

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 currentEPB was produced under; the two are verified as a pair.

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 newEPB was produced under, paired with it 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.

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

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 the card is opened at, as a number. Held as a number rather than text throughout.

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.

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

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

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.

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

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

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 the card is for. Omitted it arrives as 0, which the service refuses, as it does a negative number.

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

The caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

The delivery barcode the consignment is tracked by.

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.

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.

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.

Values:

• A — main account
• V — virement

Whether this account is the one drawn on first. The account listings return the stored value.

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

Whether a transaction in another currency is converted against this account automatically.

Whether the card may be used online.

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 here. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. A product that issues virtual cards is refused outright — this operation does not create them.

Customer the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.

The main card's shadow number.

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.

Required in practice · NotNull — Branch the application is made at. Unlike the sibling create operations this one does not demand it up front — it is checked by lookup, so an absent value is refused as a branch that was not found.

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 ignored otherwise.

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.

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 application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.

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.

Currency of the disputed amount, and the field both routes read first.

With ClearingTableName and ClearingNumber, which clearing record is being disputed. Only the integration route reads the three; the local route matches on UTID alone and drops them. The four characters are the width of what it has to match — the column on the 33 clearing transaction tables. The dispute case detail stores it in a wider column, ten characters, but a longer value would be stored and match nothing.

Which clearing table the disputed record is in. Only the integration route reads it.

Which record within that table. The contract holds a non-nullable number, so leaving the field out sends 0, and only the integration route reads it.

The acquirer's reference for the disputed transaction. Only the integration route reads it.

Required in practice — The case identifier in the external dispute system. The integration route refuses a blank one on any entry; the local route drops it. Used to match the case rather than stored by this platform.

Required in practice — The document identifier in the external dispute system. The integration route refuses a blank one on any entry; the local route drops it.

Whether the case needs special follow-up, Y or N. The integration service substitutes N for a blank, which is what makes it a one-character flag; the local route drops it.

Whether the cardholder is a VIP, Y or N. The integration service substitutes N for a blank; the local route drops it.

Document references for this entry. Only the integration route reads them — on the local route, attach documents through the request's own DmsReference instead.

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.

Plain card number of the disputed card. One of four ways to name the disputed card, and at least one of them is needed: the local route refuses the request with CardInformationRequired when all four are absent. The number itself is never stored — the case tables hold a masked form and a hash. The integration route refuses a blank one.

Shadow number of the disputed card. One of four ways to name the disputed card, and at least one of them is needed: the local route refuses the request with CardInformationRequired when all four are absent. Both routes forward it, but the integration service does not pass it on to the dispute management service, so on that route it narrows nothing.

Card reference number of the disputed card. One of four ways to name the disputed card, and at least one of them is needed: the local route refuses the request with CardInformationRequired when all four are absent. Only the local route forwards it; the integration route drops it.

Encrypted card number of the disputed card. One of four ways to name the disputed card, and at least one of them is needed: the local route refuses the request with CardInformationRequired when all four are absent. A key rather than stored data: the local route looks the card up with it and then replaces the value with the one the card service returns, and the integration route drops it.

Which side of the dispute the case is opened on. The local route accepts only the two values below and answers "Undefined Case Type" to anything else; it is stored in CMS_DIS.CASE_MAIN.IA_INDICATOR.

Values:

• I — issuer side
• A — acquirer side

Required — Date the dispute is raised. The contract holds a non-nullable date, so leaving the field out forwards 0001-01-01 rather than today, and the local route refuses that.

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.

Dispute reason. The local route looks the value up in the clearing service's reason definition table and refuses an unknown one; the codes are rows rather than constants, so they can change without a release and are not published as a fixed list. Credit's Get Dispute Reason Def List returns them.

Required in practice — Free-text explanation of the dispute. Both routes refuse a blank one, and neither declares the field required.

Not read on either route. The local route does not forward it, and the integration route forwards it to a service that then drops it. Set it on each entry of CreateDisputeCaseDetail instead, which is where the integration route reads it and refuses a blank.

Not read on either route, for the same reason as ExternalCaseId. The per-detail copy is the one that reaches the service, where a blank becomes N.

Not read on either route, for the same reason as ExternalCaseId. The per-detail copy is the one that reaches the service, where a blank becomes N.

Transactions covered by the case. The integration route refuses an empty or missing list; the local route accepts the request and then fails on the first entry, because it reads the list without a null check. The local route also forwards only three fields of each entry — see the entry's own fields.

Document references to attach to the new case. Only the identifier of each entry is forwarded, on both routes.

The dispute case this belongs to.

The transactions the case covers.

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 the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.

Product the card is issued on. Rejected when absent and when it matches no card product. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. Its segment must be Corporate: an individual product is refused here.

Branch the application is made at.

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

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 --.

Conditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is supplied and is the branch delivery type — this operation checks for an empty delivery type first, which its siblings do not.

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.

Application Date

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.

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.

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.

Values:

• A — main account
• V — virement

Whether this account is the one drawn on first. The account listings return the stored value.

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

Whether a transaction in another currency is converted against this account automatically.

Whether the card may be used online.

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

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 product the card is issued on. Must be a product the platform defines.

The customer the card is issued to.

The branch the card is issued from. Must be a defined branch.

ListHasNoItem — The accounts the card draws on. Must be sent and must hold at least one entry.

Whether to issue the card as a digital one. It also decides the default e-commerce permission where permissions leaves that unset.

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.

How the card reaches the cardholder. Branch makes cardDeliveryBranchCode mandatory.

Values:

• P — by post
• S — to the branch

Not set is "".

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 --.

Conditional · NotNull — The branch the card is delivered to. Mandatory when cardDeliveryType is Branch, and it must be a defined branch.

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

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.

A miscellaneous option to set on the card, as a type-and-value pair. Only one may be sent at creation; changeCardMiscOption sets more.

Leaving it out does not leave the option unset. No row is written, but getCardMiscOption answers for a card that has none by returning the first value configured for that option type — so the card behaves as if it had been given that value. Which value that is comes from the option-type definition rather than from this API.

Replacing a card carries the option across. Where the replaced card had none, the platform writes DS / HardCopy onto the new one.

Whether to enrol the new card with Masterpass. Forwarded to the issuing service, which does the enrolment; the card is created either 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.

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

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 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 application this request belongs to. Returned when an application is created, and carried through the card that comes out of 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.

Product the card is issued on. Rejected when absent and when it matches no card product. It must then be on the platform's applicable-product list, and that entry must name the channel this request is made from — the channel is refused against applicableProduct.ListOfApplicableChannel rather than against this field. Its segment must be Individual: a corporate product is refused here.

Customer the card belongs to. Three separate refusals — absent, zero and negative each raise their own code — and the customer must then exist, be active, and be within the product's age range.

The main card's shadow number. Its master must carry a main customer and that customer must be active.

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

ListHasNoItem — The accounts the card draws on. A debit card is issued against accounts, so an absent or empty list is refused — this is the check credit's equivalent operation does not have.

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.

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 --.

Conditional · NotNull — Branch the card is delivered to. Required when cardDeliveryType is the branch delivery type, and ignored otherwise.

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

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.

A miscellaneous option to set on the card, as a type-and-value pair. Only one may be sent at creation; changeCardMiscOption sets more.

Leaving it out does not leave the option unset. No row is written, but getCardMiscOption answers for a card that has none by returning the first value configured for that option type — so the card behaves as if it had been given that value. Which value that is comes from the option-type definition rather than from this API.

Replacing a card carries the option across. Where the replaced card had none, the platform writes DS / HardCopy onto the new one.

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

Application Date

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.

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 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 application this request belongs to. Returned when an application is created, and carried through the card that comes out of 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 customer the application is for. Omitted it arrives as 0, which the service refuses, as it does a negative number.

When absent the facade picks a no-name product for the channel, digital or physical as digitalCard asks. Sent, it must be a defined product.

Default — Defaults to false. Read only when productNumber is absent, to pick a digital or a physical no-name product; once the product is known the facade overwrites it from the product's card form.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

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.

The caller's own identifier for this request, stored against the application so the two can be reconciled later. The platform does not interpret it.

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

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

The card application this request belongs to. Returned when an application is created, and carried through the card that comes out of 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 related card's shadow number — the card the virtual card draws on. Its status must allow one, and the customer may hold only one virtual card per related card.

ListHasNoItem — The accounts the card draws on. A debit card is issued against accounts, so an absent or empty list is refused — this is the check credit's equivalent operation does not have.

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

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.

The card this one is related to, where it is.

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.

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.

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.

Which kind of card, as the one-letter code the account type carries: C credit, D debit, P prepaid.

Whether this is a supplementary card rather than a main one.

Whether this is the card currently in force under its reference, as opposed to one it replaced.

The branch the card is opened at, as a number. Held as a number rather than text throughout.

Whether the card is a virtual one.

Whether to issue the card as a digital one. It also decides the default e-commerce permission where permissions leaves that unset.

Whether the card carries a chip.

Whether the card carries a magnetic stripe.

Whether the card can be used contactlessly.

Whether the transaction earned a reward.

Whether the authorisation is still held against the limit.

How many verification-value attempts are left before the card blocks.

How many PIN attempts are left before the card blocks.

Whether a replacement has been asked for and not yet produced.

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 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.

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 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 main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.

The card this one is related to, where it is.

The branch's name.

The cardholder's first name, as the customer record holds it.

The cardholder's middle name, where there is one.

The cardholder's surname, as the customer record holds it.

The name embossed on the card.

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

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.

The card product's full name.

The card product's short name, for a list or a statement line.

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

Which scheme the card is issued on.

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

Values:

• P — by post
• S — to the branch

Not set is "".

The card's expiry as MMYY.

Values:

• P — physical
• D — digital
• B — physical and digital — a product setting, resolved to P or D at issue
• H — HCE
• T — token
• V — virtual

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.