Card issuance and personalisation
Create individual, corporate and virtual cards, and check which products a customer is eligible to hold before you issue.
createIndividualCard
Creates an individual prepaid card for a customer.
Part of:
- Journey 01 · Launching a new card product — step 2, Issue from stock
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
createIndividualCard › Request Body
channelThree-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.
productNumberThe product to issue on. Leaving it out does not fail — it chooses. The facade reads the products applicable to the customer and takes the first one in that list, logging what it picked; which product is first is the platform's ordering, not a preference this API exposes. A customer with no applicable product is refused.
Sent, it must be a product the platform defines.
customerNumberDefault — Defaults to 0, and 0 issues the card without a customer: the service skips the customer lookup. The customer the card belongs to. It is also what the automatic product choice above is made against.
mainCustomerNumberThe main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.
mainCardRefNumberThe 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.
branchCodeDefault — Defaults to 0. The branch the card is opened at. It is not checked against the branch list.
cardDeliveryTypeValues:
P— by postS— to the branch
Not set is "".
cardSendAddressTypeValues:
RA— homeAL— businessEA— employerOO— alternativeWA— previousSW— SWIFTSS— SWIFT name and addressMR— Mernis, registeredMS— Mernis, stated
Not set is --.
cardDeliveryBranchCodeThe branch the card is delivered to.
enrollMasterpassWhether 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.
contractTypeWhich cardholder contract the customer accepted. The pair with contractVersionNumber records what was agreed to and when.
contractVersionNumberWhich version of that contract the customer accepted.
nameOnCardThe 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.
cardSendAddressIdA stored address to send the card to. The facade turns it into a single card-address entry of the send type; omitted, no address list is sent at all and the delivery fields alone decide.
applicationDateA 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.
applicationContractIdThe contract record in the application system that this card comes from.
createIndividualCard › Responses
Issued. The response carries the new card's references — shadowCardNumber, cardRefNumber, mainCardRefNumber, the masked number and the record id — and a warnings list.
Read warnings. It comes from the issuing service and is returned on a successful call, so a card can be created with something worth knowing attached to it. An empty list is the untroubled case.
A prepaid card is issued with no limit: what it can spend is a loaded balance held on a wallet, and loading that balance has no published operation on this portal.
recordIdThe identifier of the row the operation created or acted on, returned so a later call can name it.
maskedCardNumberThe card number with its middle digits masked, as the platform stores it. It is a display form, not a key.
shadowCardNumberThe 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.
cardRefNumberThe card reference, which identifies one issued card including its renewals. Returned by the create and listing operations alongside the shadow number.
mainCardRefNumberThe 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.
applicationIdThe card application this request belongs to. Returned when an application is created, and carried through the card that comes out of it.
getApplicableProductsByCustomerNumber
Gets applicable prepaid products by customer number.
Headers
evrst-ptrnidCorrelation id for this request. Echo it in your own logs to trace the call through the platform.
getApplicableProductsByCustomerNumber › Request Body
channelThree-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.
customerNumberThe 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.
mainCustomerNumberThe main customer of a corporate relationship, as a number. The employees and supplementary holders under it carry their own customerNumber.
Which rows to return. Left out, the operation returns them all.
getApplicableProductsByCustomerNumber › Responses
Success
The products the search matched.