API Reference
Changelog UpdatesAPI StatusSupport

Issue Card (Instant)

post
https://partner-api.getpliant.com/api/cards//instant

This endpoint offers similar card issuing functionality as the main card issuing endpoint, but specifically allows for a synchronous and instant card issuing, whereas the main card issuing flow works asynchronously and requires the consumption of a callback to confirm the card is actually active. This endpoint issues cards instantly in a synchronous fashion. Meaning the card is active and usable when this endpoint returns a 200 Ok response. The use case being here a fully automated card issuing flow, followed by an immediate card usage on API level for normally PCI-DSS certified companies. Please note, that the sensitive card data still needs to be fetched separately after issuing a new card (if PCI-DSS compliant).

This endpoint should only be used if aligned with Pliant upfront. In 90% of cases, you want to use the normal card issuing endpoint instead, as linked above.

Path Params
uuid
required

The id of the cardholder to issue the card for. This cardholder needs to have a phone number, otherwise 3DS security mechanism during a purchase will not work.

Body Params
uuid
required

The ID of the organization to issue the card for.

uuid

The ID of the card account to issue the card for. If not provided, the card will be issued for the default card account of the organization.

string | null
enum
deprecated

Deprecated, please use cardConfig instead. VIRTUAL - Virtual credit card SINGLE_USE - One-time virtual credit card (only one authorization allowed per card)
PHYSICAL - Physical credit card BLACK - Physical black premium credit card TRAVEL - Virtual cards used specifically in travel industry related use cases Either type or cardConfig has to be provided. Please prefer cardConfig.

Allowed:
string
required

The Pliant card configuration of this card. This describes all features of this card in one single configuration, e.g. the type of the card and also the design of the card etc. It replaces the deprecated card type. Please refer to the guide section to learn more about possible values. Either type or cardConfig has to be provided. Please prefer cardConfig. Required for INSURANCE cards - the deprecated type field cannot be used.

uuid | null

The unique identifier of the card design used for this card. This field can only be set when creating virtual cards. Available designs for a card config can be retrieved via the available cards endpoint.

string | null

Mandatory only for virtual cards with a cardConfig containing VIRTUAL or TRAVEL, the maximum length is 40 characters.

string
length ≤ 200

Mandatory only for virtual cards with cardConfig ending with SINGLE_USE

number
enum

Number of months when card expires.

  • Mandatory for cardConfig containing VIRTUAL and TRAVEL
  • For cardConfig ending with PHYSICAL or BLACK: set to 36 months automatically
  • For cardConfig ending with SINGLE_USE: set to 12 months automatically
  • For cardConfig containing INSURANCE:
    • Physical insurance: set to 24 months automatically
    • Virtual insurance (excluding single-use): validated from enum, defaults to 36 months
    • Single-use insurance: set to 12 months automatically For cards with fixed validity periods, user input is ignored.
date | null

Optional field to describe a fixed date range in which the card is usable for purchases, replaces the validityPeriod if used. Outside of this date range, the card cannot be used for any purchases, only for zero-amount card-checks, and is shown with status PENDING. If not provided, the card is active immediately. Date needs to be provided as yyyy-mm-dd and is treated inclusive, meaning the provided date is already a valid day to use the card. If used, the parallel usage of card controls regarding dates and/or times is not allowed and the validityPeriod will be set to 36 months automatically. The earliest possible date is the current date. The validFrom date needs to be before the validTo date. The fields validFrom, validTo and validTimezone need to be used together, if used at all. This feature is only available for cards with a cardConfig containing TRAVEL or TRAVEL_CC, marking them as travel cards. This field can be updated later. This field must be null when issuing benefit cards.

date | null

Optional field to describe a fixed date range in which the card is usable for purchases, replaces the validityPeriod if used. After the specified date, the card is automatically terminated. If not provided, the card is active until the validityPeriod ends. Date needs to be provided as yyyy-mm-dd and is treated inclusive, meaning the card will be terminated one day after this date. If used, the parallel usage of card controls regarding dates and/or times is not allowed and the validityPeriod will be set to 36 months automatically. The latest possible date is the end date of the validityPeriod. The fields validFrom, validTo and validTimezone need to be used together, if used at all. This feature is only available for cards with a cardConfig containing TRAVEL or TRAVEL_CC, marking them as travel cards. This field can be updated later. This field must be null when issuing benefit cards.

string

Optional field to describe the timezone for the validFrom and validTo fields. This field is mandatory if validFrom and validTo fields are used. A list of valid timezones can be found in our guide section. This field can be updated later. This field must be null when issuing benefit cards.

number
1 to 999999999

❗ IMPORTANT: if the cardConfig is TRAVEL and this field is not set, the default value will be 5. Optional field to describe the maximum number of transactions within the range of 1..999999999 that can be performed with this card. If not provided, the card can be used for an unlimited number of transactions until the card expires.

monthlyLimit
object
deprecated

Use limit instead.

limit
object
required

The limit of the card. The limit renews according to the limitRenewFrequency or never, if limitRenewFrequency is set to TOTAL. This limit can later be adjusted via the update limit endpoint. The limit can be up to the organization's overall limit. For instance an organization with a limit of 1,000,000 EUR can have a card with a limit up to 1,000,000 EUR. It is also possible to have more than one card with the maximum limit. For example you can have two cards each with a limit of 1,000,000 EUR. The card limits are not added up on creation, only the transactions happening on the card are added up and checked against the organization's overall limit. The limit must be 0 (of the card's currency) when issuing benefit cards.

string
enum

The frequency of the card limit renewal.

  • DAILY - The card limit is renewed every day
  • WEEKLY - The card limit is renewed every week
  • MONTHLY - The card limit is renewed every calendar month, this is the default setting.
  • QUARTERLY - The card limit is renewed every calendar quarter.
  • ANNUAL - The card limit is renewed every year.
  • TOTAL - The card limit is never going to be renewed. After the limit is spent the card cannot be used anymore.
Allowed:
transactionLimit
object
required

The transaction limit of the card. Meaning the maximum amount of a single transaction. This is always below or equal to the limit of the card. This limit can later be adjusted via the update limit endpoint. The transaction limit can be up to the card's limit. For instance a card with a limit of 1,000 EUR can have a transaction limit up to 1,000 EUR. The transaction limit must be 0 (of the card's currency) when issuing benefit cards.

string | null

Optional first name on TRAVEL cards which will be used on the card. When used, this replaces the cardholder first name, which normally is used on the card. The maximum length of customFirstName is 50 characters. If used, both fields (customFirstName and customLastName) have to be provided with at least one character each. It is important to note, that only the following characters are allowed for issuing cards: A-Z, a-z, 0-9, äöüÄÖÜ.-

string | null

Optional last name on TRAVEL cards which will be used on the card. When used, this replaces the cardholder last name, which normally is used on the card. The maximum length of customLastName is 50 characters. If used, both fields (customFirstName and customLastName) have to be provided with at least one character each. It is important to note, that only the following characters are allowed for issuing cards: A-Z, a-z, 0-9, äöüÄÖÜ.-

cardControls
object
customFields
array of objects | null

Optional custom fields which can be set on a card. A custom field may have a default value which will be copied to every transaction made with this card. You can identify a custom field either by its id or its label. If both are provided, the id will be used. You can also create new custom fields (of type TEXT) on-the-fly by providing a newly, unused label and the corresponding default value you want to set. So mainly two uses cases exist: 1. Use an existing custom field on the card, mostly identified via its id. 2. Create a new custom field (of type TEXT) on-the-fly via the label and set it on the card.

customFields
uuid | null

The ID of the team to issue the card for.

uuid | null

The ID of the project to issue the card for.

copilots
object | null

Optional feature for TRAVEL cards. This feature allows to assign cardholders or teams as copilots to the card. The copilot also has access to the card and its card details alongside with the cardholder of the card itself.

string | null
enum

Optionally, specifies where the physical card should be delivered.

  • ORGANIZATION - Ship to organization address (default)
  • CARDHOLDER - Ship to cardholder's personal delivery address

This field is only applicable for physical cards. If not provided, the card will be shipped to the organization address.

The request will fail if the cardholder's personal delivery address is not set and deliverTo is set to CARDHOLDER.

Allowed:
Responses

Updated 8 months ago

Language
Credentials
Bearer
JWT
URL
LoadingLoading…
Response
Choose an example:
application/json

Updated 8 months ago