Changelog
API StatusSubscribe To Updates

Exposing FX Fee data

We are exposing our FX fee data now. These enhancements improve transparency and detail for API consumers interacting with foreign exchange rates and fees through our CaaS API.

FX fee on organization & transaction and account entry entity level

  • FX Rate Field:

    • Added fx_rate field to the GET /organization endpoint, enhancing organization details by including foreign exchange rate information.
    • Updated the ORGANIZATION_UPDATED callback payload to include the fx_rate field. This field will now be part of the payload when an organization update is triggered, allowing partners to receive real-time updates on FX rates.

  • FX Fee Object:

    • Added fx_fee object to the GET /transaction endpoint, providing detailed foreign exchange fee information for transaction details.
    • Introduced the fx_fee object to the GET /account_entry endpoint, specifically for entries where type = TRANSACTION, enabling better visibility of FX fees associated with account entries.

Minor improvements

We have made small improvements to the transaction, statements and card account entities.

Set receiptNeeded flag on on transaction level

We have added an endpoint that allows to manage the necessity to provide receipts within the Pliant platform (web apps, mobile app). Its now possible to turn receiptNeeded property to false on transaction level allowing for some automations based on e.g. card or merchant level. As API consumer you can now turn off receipts for specific merchants or cards. The endpoint is documented here: PATCH /transactions/{{transactionId}}/receiptUpload.

Balance for each card account

Previously the balance property has been only available on organization level. We have now added it to the card account entity. It can be accessed via this endpoint GET /card-accounts. More information on the topic of account limits and balanced can be found in this article.

Related transactions for statement entity

Each statement has a 1:1 relationship to account entries. It is now possible to fetch all account entries for a given statementId. We extended the existing endpoint GET /statements/{{statementId}} to fetch the details of a statement with the relatedTransaction property.

Adjusted length of custom names and new payment webhook

New custom names character length

We are improving our cards service adjusting the maximum characters of customFirstName and customLastName to a total of 100 (from the current 25).

This change will be especially relevant for travel consumers.

Additional payment webhook

We introduced a new webhook, PAYMENT_READY. API Reference

With this new webhook consumers will be able to identify when a bill payment is complete (= no more transactions will be added to that payment).

Account entries endpoints

We introduced a new endpoint to retrieve account entries for a set organization. Account entries are basically all movements of a card account. The endpoint will enable you to fetch booked account movements and provide detailed account informations, together with the statements endpoint.

Various new endpoints & improvements

We are introducing a way to retrieve the statement CSV (helpful for reconciliation) as well as an endpoint to migrate non-embedded cardholders to embedded ones (to restrict access to Pliant UIs). In addition to that, we added a new request property for deactivating cardholders and a new callback that is fired once a card is shipped by one of our card manufacturers.

Statement CSV

Until know we only exposed the monthly statement PDF including all the account movements (we call them "account entries") like credit card transactions, bill payments, direct debit reversal fees and so forth. We are now adding an endpoint that allows fetching the so called statement CSV. Usually this file is attached to the monthly billing email (next to the statement PDF) but can also be downloaded for each month using Pliant UI.

To access the file:

  1. Call POST /statements/csv to trigger the file creation job for the specified organization, card account and date period.
  2. You will receive a callback of type STATEMENT_CSV_DOWNLOAD_READY once the exported CSV file is ready. Do not forget to subscribe to the callback upfront! Otherwise this endpoint returns an error.
  3. Fetch the actual file via the URL that is provided in statementFileUrl. This URL is valid for at least 1 week. After that, the file might not be available anymore. The pattern of this URL may change at any time, so do not rely on the structure of the URL. Every time you receive the callback, just use the provided URL in the callback to download the file.

Remarks to the business logic: You can specify start and end dates. In the Pliant application, for all completed months, these dates default to the first and last day of the month. For the ongoing month, the start date defaults to the first day of the month, and the end date is set to the current day.

Change cardholder type

When adding cardholders to the platform we do offer two ways

  1. Inviting them via POST /cardholders/invite which sends out an email and asks the user to go through the registration flow (setting a password and more). This results in a user with full access to the Pliant UI (depending on role)
  2. Registering them via POST /cardholders/register which creates an entity on the platform that can be used to issue cards (via API or UI). The user does not receive any email and is not able to access Pliant applications (web or mobile)

Internally we do handle those cardholders differently. The first ones are non-embedded cardholders while the latter ones are embedded cardholders.

We are know adding an endpoint POST /cardholders/remove-pliant-webapp-access that allows you to migrate an non-embedded cardholder to an embedded cardholder. This is especially useful if you want to restrict access to Pliant apps (web & mobile).

Some important remarks:

  • The endpoint asks for mandatory parameter organizatioId because in case a cardholder is the member of multiple organisations you are able to restrict only access to the specified organization. If you want to lock out a cardholder completely provide the same cardholderId in combination with multiple organizationIds.
  • It wont change anything in case the cardholder is in terminated status or if the cardholders role is ADMIN or OWNER.

Deactivate cardholder

It was possible for a long time already to deactivate cardholders by calling DELETE /cardholders/{cardholderId}.

Sometimes there is the business need to deactivate a cardholder and re-invite the cardholder with the same username (email address). This is why we are adding an optional suffix parameter when calling the above mentioned endpoint that allows API consumers to alter the username by adding a suffix like +deactivated to the email address that is stored on the platform.

Business logic:

  • If no suffix is applied the cardholder will be deactivated without any change of the username
  • If the endpoint is called for already deactivated cardholders the suffix will be applied as well.

Minor improvements

  • We're introducing a new event: CARD_SHIPPED. This event will be triggered when we receive confirmation from our card manufacturers that a physical card has been successfully shipped. Please note that this event is applicable only for cards designated as PHYSICAL and will not be triggered for any other card types. The payload is re-using the cardUpdate object described in our API reference for card entity.
  • We added the cardId to the payload of CARD_REQUEST_UPDATED callback that is triggered by the following events: CARD_REQUEST_CREATED, CARD_REQUEST_APPROVED & CARD_REQUEST_REJECTED.

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.