Changelog
SupportAPI StatusSubscribe To Updates

Change of base URL for test environments

Pliant is deprecating the current base URL for its API test environment, also known as sandbox or staging environment. This means you need to switch the base URL for the test environment from the currently used one to our new base URL.

This change only affects the test environment of the Pliant CaaS / Pro APIs as well as the PCI APIs.

Change for the CaaS/Pro API:
From partner-api.staging.v2.infinnitytest.com to sandbox.partner-api.getpliant.com
Example full endpoint URL after the change: GET https://sandbox.partner-api.getpliant.com/api/organizations

Change for the PCI API:
From pci-api.staging.infinnitytest.com to pci-sandbox.partner-api.getpliant.com
Example full endpoint URL after the change: GET https://pci-sandbox.partner-api.getpliant.com/card-details/widget/…/otp

Everything else stays the same!

  • This change only affects the test environment, NOT the production environment.
  • No change is planned for the production environment URLs.
  • No endpoint path or structure itself changes, just the base URL.
  • The calls are still HTTPS encrypted, as usual.
  • The API docs already reflect this change.
  • Auth0 URLs and parameters are not changed.

Why do we change?

  • Better readability of the base URL itself
  • Better scaling options on our end in the future

In 6 weeks from now, on 31st May 2024, Pliant will discontinue the routing of the old, deprecated base URL. Calls to the old URLs will fail after this point in time.

The new URLs are available immediately and you can switch within the next 6 weeks from now on.
If any questions around this change arise, please use the established communication channels.

New entity: Card Account

With the addition of card accounts we do support multi-account setups now. Eventually card accounts are going to be used in multi-currency contexts.

Card Account Entity

Context

We've introduced a new multi-account functionality, enabling organizations to set up multiple accounts with separate billing settings tailored to their unique business needs. This feature is ideal for customers who would like to implement different billing accounts for different groups of cards, for example, for different branches of the same legal entity. This is part of our efforts to support multiple currencies. In addition to that it enables 1:n relations between your customers and the Pliant organization (id).

Hint: Within Pliant UI when the feature is activated, additional card accounts can be created via a new "Accounts" tab, and the right account selected when issuing or requesting new cards.

Changes

Additions

We added a new endpoint (including callbacks) that returns a list of all card accounts for the given organization. Each organization has at least one active card account. Card accounts get created during the onboarding process but can also be added later. If multiple card accounts are used, there is exactly one active default card account. This default card account is used if no card account is specified in the request, where card accounts can be used, like when issuing a card. Each card account has one fixed currency for settlements. This currency is used for all transactions made with cards of this card account. More details can be found in our guides section.

  • New endpoint: GET /api/card-accounts
  • New Callbacks:
    • CARD_ACCOUNT_DETAILS_CHANGED triggered when a new card account is created or once data about an existing card account is changed/updated
    • CARD_ACCOUNT_BALANCE_CHANGED
    • CARD_ACCOUNT_LIMIT_CHANGED

Improvements

IMPORTANT:

  • All these changes are backwards compatible as the parameter is optional in most cases because every organization always has one default card account that we use when no cardAccountId is specified by the API consumer.
  • For the List endpoints that respond with an array of entities the cardAccountId can be used to filter the result set.

Callback Improvements: New events & Callback log

Convenience transaction related events for easier reconciliation and a way to check if you missed any events.

Transaction events

For businesses, particularly within the travel sector, reconciling credit card transactions is essential. To streamline this process and alleviate the challenges associated with managing various transaction states, we are introducing two new convenient callbacks for the transaction entity. These enhancements simplify reconciliation and ensure you don't miss critical transaction updates.

  • TRANSACTION_AUTHORIZED: Triggered whenever a transaction reaches the AUTHORIZED status.
  • TRANSACTION_CONFIRMED: Triggered whenever a transaction reaches the CONFIRMED status.

Callback log

Our API extensively utilizes callbacks to enable real-time processing of events. To support this, we now offer an endpoint to retrieve logs of all emitted events: GET Callback Logs.

This endpoint is particularly useful for verifying the events you are subscribed to and checking for any missed callbacks.

Logo cards & minor improvement

We are excited to announce the introduction of logo cards to our platform. Additionally, we have addressed a minor issue that previously could result in unintended platform configurations during the process of updating organization data.

Support for Logo Cards

Logo cards are a special type of Pliant card that features both the Pliant logo and the logo of a company or partner. This enhancement allows API consumers to differentiate between standard cards and logo cards easily. To facilitate this, we've made the following updates to our endpoints:

  • Enhanced Endpoint Responses: The GET /api/cards and POST /api/cards/details endpoints now include two new fields in their responses: cardDesignId and cardDesignLogoName. These fields allow for identifying the card's design and logo name, respectively.
  • List Support for New Properties: The GET /api/cards/available-cards endpoint has been updated to return cardDesignId and cardDesignLogoName as part of a list in its response.

Please note that logo cards will use the same cardDesign value as standard Pliant cards to indicate the card design chosen by our processing partner or, for physical cards, the card manufacturer.

Update on Missing Receipt Notification Configuration

  • Visibility on missingReceiptNotification Status: To enhance transparency and control, we've updated the GET /api/organizations/{organizationId} endpoint. It now allows users to view the currently stored state of the missingReceiptNotification status. Previously, providing a null when updating organization data via PATCH /api/organizations/{organizationId} was akin to setting the flag to false, which could lead to unintended behaviour.

Custom fields

We are adding custom fields to card and accounting transaction entities.

Custom fields

Custom fields are a way to assign default values on the card level that are being applied to every transaction and can be accessed while fetching 1-n accounting transactions. More details can be found in our guides section.

In short:

📘

Only available in v2.1.0

Advanced card controls

We are adding more flexibility when setting up card controls.

Advanced card controls

  • It is now possible to add validFrom, validTo and validTimezone values directly when issuing a card.
  • It is now possible to define a value for maxTransactionCount when issuing a card. If not provided, the card can be used for an unlimited number of transactions until the card expires.
  • The above-mentioned properties have also been added to the response Card details.
  • There is a new endpoint Available card configs that allows to check which card configs are available to issue for the given organization.
  • Cards that have been locked due to a card control being applied (LOCKED_CC_DATETIME, LOCKED_TX_COUNT) cannot be unlocked via the unlock card endpointCards anymore.
  • We added a new endpoint to issue cards instantly. 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 active. 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. This endpoint should only be used if aligned with Pliant upfront.

📘

Only available in v2.1.0

Get cashback information

We now offer several endpoints to fetch cashback information for a specific organization.

  • You can fetch the cashback configuration per organization.
  • Get the cashback amounts or history of paid cashbacks,
  • as also the receipt for the paid cashback and
  • the cashback per transaction.

📘

Only available in v2.1.0

Card Controls are now available

We added several card controls, to better customize the card experience and which merchants, transaction categories or dates are allowed (or blocked).

You can now allow or block the following things on our credit cards:

  • transaction categories like "IT Equipment" or MCCs, Merchant Category Codes,
  • merchant by names, like Amazon or merchants by technical identifiers,
  • date ranges and specific dates.

You can find details about this new functionality in our guides section and also in the API reference if you want to look at the endpoints directly.

📘

Only available in v2.1.0

Quality of life improvements II

We improved several parts of our API, especially for the organization & transaction platform entities.

Update organization data

It is now possible to update organization details via 🔗 PATCH /organization/{organizationId}. You are able to update

  • Partner Organization ID (partnerOrganizationId)
  • Billing email address (billingEmail)
  • VAT ID (vatId)
  • Delivery Address for the physical cards (deliveryAddress)
  • Trade name (tradeName)
    💡 An organization may use a different name, e.g. for marketing purposes. In case a trade name is provided, this will be the one printed on the employees' physical cards, instead of the organization's legal name.

In addition to that it is now possible to turn on/off notifications and icons for missing receipts via the missingReceiptNotifications property.

Update payment category (transactions)

When a transaction is created we assign a transaction/payment category to the transaction based on our internal mapping of merchant category codes (MCCs). Sometimes this does not fit consumers' needs. That's why we enable you to update the transaction/payment category for a single transaction via 🔗 PATCH /transactions/{transactionId}/category.

In the case of split transactions (accounting transactions), all split transactions will have a new category assigned.

Merchant logo & additional merchant data

📘

This feature is only available in API Version 2.1.0

We start exposing cleaned-up merchant names (merchantData.displayName) and merchant logo data (merchantData.logoPath) from Pliants merchant database. We plan to add additional features hence we also start exposing the Pliant merchant ID (merchantData.pliantMerchantId).

In addition to that, we added additional data that we directly receive from the card processor like data that is part of the confirmation message (merchantRawData.descriptionConfirmation). This includes e.g. ticket numbers for airline bookings that we only receive with the second (confirmation) call. In the scope of this feature, we completely revamped the way how we expose merchant data for single/multiple transactions.

{
  "mcc": "1234",
  "mccDesc": "Test Merchant Description",
  "merchantId": "123456789",
  "merchantStreet": "Sonnenalle 42",
  "merchantCity": "Vienna",
  "merchantRegion": "AT",
  "merchantPostcode": "1020",
  "merchantCountry": "Austria",
  "merchantPhone": "(123) 456-7890",
  "merchantUrl": "https://www.dummy-merchant.com",
  "merchantName": "Test Merchant Name",
  "merchantLegalName": "Test Merchant Ltd.",
  "merchantNameOther": "Test Merchant Name Other",
  "merchantTaxId": "DE123456789",
  "merchantContact": "[email protected]",
  "merchantTerminalId": "1a2b3c4d"
}

"merchantData": {
  "pliantMerchantId": "023ec4fb-1564-4fa1-8bd9-7b981601eae2",
  "displayName": "Test Merchant",
  "logoPath": "logos.getpliant.com/023ec4fb-1564-4fa1-8bd9-7b981601eae2.png?v=2"
},
"merchantRawData": {
  "mcc": "1234",
  "mccDesc": "Test Merchant Description",
  "merchantStreet": "Sonnenalle 42",
  "merchantCity": "Vienna",
  "merchantRegion": "AT",
  "merchantPostcode": "1020",
  "merchantCountry": "Austria",
  "merchantPhone": "(123) 456-7890",
  "merchantUrl": "https://www.dummy-merchant.com",
  "merchantNameOther": "Test Merchant Name",
  "merchantLegalName": "Test Merchant Ltd.",
  "merchantTaxId": "DE123456789",
  "merchantContact": "[email protected]",
  "merchantTerminalId": "1a2b3c4d",
  "descriptionAuthorization": "Dummy Merchant Message",
  "descriptionConfirmation": "Dummy Merchant 1234567"
}

This applies to the response payload of the following endpoints/callbacks:

❗️

Important

With this change we also deprecate the endpoint to fetch details for a single transaction in 2.1.0. as this functionality is offered within the batch endpoint by providing a single transactionId.