Card issuance and personalisation

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 defined, applicable, and have at least one applicable channel.

The customer the card is issued to.

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

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.

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

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.

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.

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

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.

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

The currency the statement is produced in.

Which kind of address that is.

Whether the statement is posted on paper.

Whether the statement is announced by SMS.

Whether the statement is sent by e-mail.

Which of the customer's addresses the statement is posted to.

The spending limit to open the card with.

The limit for the customer behind the card, which the card's own limit draws against.

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

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

How many instalments a purchase is split into automatically, where the product allows it.

How many months a purchase is deferred automatically, where the product allows it.

Whether the card takes part in automatic limit increases.

Whether the card's debt is paid automatically. The account it is paid from is autoPaymentAccount, which is only read when this is true.

The account automatic payment draws on. Read only when autoPaymentFlag is true; otherwise no payment order is created.

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.

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 supplementary 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, that entry must name at least one channel, and it must name the channel this request is made from — the last two are refused against applicableProduct.ListOfApplicableChannel rather than against this field. Its segment must be Individual: a corporate product is refused here.

Customer the supplementary card belongs to. Rejected when absent and rejected again when it is zero, which is a separate check and a separate code from the null one.

The main card's shadow number, not the supplementary card's — the supplementary card does not exist yet. The card it names must be a card master, and that master must carry a main customer, a limit, a product and a financial record; each is a separate refusal.

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

Ask for the card to be issued as digital. Refused when the product has no digital card ability. A customer who has already reached the product's digital card allowance for the year is refused separately, as a business failure rather than on this field.

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.

Conditional · NotNull — Where the card is delivered. Required when the product issues a physical card, and then it may not resolve to None. Not read for a card issued as digital only.

Values:

• P — by post
• S — to the branch

Not set is "".

Which of the customer's addresses the card is sent to. Only checked when a value is 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 the branch it names must exist. 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.

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

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.

How many instalments a purchase is split into automatically, where the product allows it.

How many months a purchase is deferred automatically, where the product allows it.

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

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.

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 dummy 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. Nothing here consults the applicable-product list.

Customer the card belongs to. Rejected when absent and again when zero.

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.

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

The currency the statement is produced in.

Whether the statement is posted on paper.

Whether the statement is announced by SMS.

Whether the statement is sent by e-mail.

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

Which of the customer's addresses the statement is posted to.

The spending limit to open the card with.

The limit for the customer behind the card, which the card's own limit draws against.

How many instalments a purchase is split into automatically, where the product allows it.

How many months a purchase is deferred automatically, where the product allows it.

Whether the card takes part in automatic limit increases.

Whether the card's debt is paid automatically. The account it is paid from is autoPaymentAccount, which is only read when this is true.

The account automatic payment draws on. Read only when autoPaymentFlag is true; otherwise no payment order is created.

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

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.

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.

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 a virtual card, and it must carry a financial record and an available limit.

How the virtual card's limit behaves. Rejected when blank, and rejected when it resolves to None — that second refusal carries the code InvalidLimitType, which the service builds by hand rather than taking from ValidationErrorCodes.

Values:

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

Not set is N.

Conditional · NotNull — Whether the limit is released at end of day. Required when limitType is the fixed type, and checked in a second pass after the other fields have passed — so a request missing both this and limitType is refused for limitType first.

Default — Defaults to 0. The virtual card's limit. It may not exceed the related card's available limit.

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

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 applicable products are read. Three separate refusals: absent, zero, and negative each raise their own code.

Main customer to read against. Not required, but when supplied it may be neither zero nor negative.

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 rows to return. Left out, the operation returns them all.

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 main customer the control is run for. Refused when absent, and when supplied it may be neither zero nor negative. The control is about this customer alone — no card or product is named anywhere in the request.

Mandatory here, unlike on getApplicableProductsByCustomerNumber where the same filter may be left out: the service refuses a request whose filter.productGroupCode is absent.

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 delivery barcode the consignment is tracked by.

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

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

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 statement period the card is billed on. The periods a product allows come from the reference data.

The currency the statement is produced in.

The spending limit to open the card with.

The limit for the customer behind the card, which the card's own limit draws against.

Whether the card takes part in automatic limit increases.

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.

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.

The card whose pending emboss records are listed. The only field the request carries, and the only thing checked.