We have added a status page that allows you to monitor our APIs as well as subscribing to updates about incidents via Slack or Email

New status page

• You can find the status of Pliants APIs by navigating to https://pliant-api.statuspage.io/
• You are able to subscribe via E-Mail or Slack to be notified whenever we create, update or resolve an incident.

🚧

Breaking change 2.0.0 -› 2.1.0

We are introducing more granular card status information which helps you e.g identifying if the card has been locked by the user deliberately or because the PIN was entered incorrectly more than 3 times.

Granular card status

The following endpoints are modified

• GET /cards (query & response parameter)
• GET /cards/{cardId} (response parameter)
• POST /cards/details (response parameter)
• POST /cards/subscription (new event CARD_STATUS_UPDATED with callback payload cardStatusUpdated)

The allowed ENUM values for the new property detailedStatus are listed below:

PENDING_ACTIVATION
PENDING_ISSUANCE
PENDING_REGISTRATION
REQUEST_APPROVED
REQUESTED
REQUEST_CANCELLED
REQUEST_REJECTED
ACTIVE
LOCKED
LOCKED_PIN
EXPIRED
TERMINATED
TERMINATED_LOST
TERMINATED_STOLEN

📘

This change is only available in API Version 2.1.0

Minor changes

• We added the type property as a query parameter and to the response of the GET /cards endpoint.
• With version 2.1.0 we are removing endpoints related to the Bills entity (details see https://partner.getpliant.com/changelog/statements-booking-datethis changelog article) completely from our API.

We are adding new endpoints to handle card limit change requests.

Card limit requests

While API consumers have long been able to update card limits directly, card limit change requests have been only available through the Pliant UI. Now we are introducing new endpoints that enable you to create, fetch, list, approve, reject and cancel card limit change requests:

• Create a new card limit change request
  POST /cards/limits/requests
• Get a list of all card limit change requests
  GET /cards/limits/requests
• Get details for an existing card limit change request
  GET /cards/limits/requests/{cardLimitRequestId}
• Cancel an open card limit change request
  DELETE /cards/limits/requests/{cardLimitRequestId}
• Approve an open card limit change request
  POST /cards/limits/requests/{cardLimitRequestId}/approve
• Reject an open card limit change request
  POST /cards/limits/requests/{cardLimitRequestId}/reject

Remarks on the business logic:

• Only one card limit request can be PENDING per card. In case there is already a card limit request open for one card and you are creating another one the API responds with a helpful error message.
• Only card limit requests with the status PENDING can be cancelled as APPROVED, REJECTED and CANCELED are considered as final status.

Minor improvements

• In the scope of this change, we are also adding a new endpoint to cancel card requests
  DELETE /cards/requests/{cardRequestId}

We are adding new batch endpoints that can be used to update the partnerSubmissionStatus of a given set of transactions and/or payments.

Batch endpoints for partnerSubmissionStatus

We are introducing two new endpoints that enable you to update the partnerSubmissionStatus for multiple transactions or payments.

• POST /transactions/partner-submission-status
• POST /payments/partner-submission-status

If there is an error with one of the transactions (e.g. because the transition is not allowed for the given transactionId) we do process all other transactions and return the list of untouched transactions.

See this page in the documentation to get to know more about partnerSubmissionStatus property and business logic.

We are adding a new endpoint that allows replacing cards.

Replace cards

We are introducing a new endpoint POST /cards/{cardId}/replace that enables you to replace existing cards with new ones.

• When replacing cards all existing configurations will be set up automatically based on the values of the existing card (e.g. limit, transactionLimit ...)
• The big advantage of replacing cards (in comparison to terminate and re-issue a new card) is that most subscriptions (that have been set up using the payment data of the replaced card) will still continue to work without updating the payment data. To put it differently: Most merchants (especially big ones) will still be able to deduct money using outdated payment details (PAN, CVV and expiry date). This effectively reduced the danger of failed payments until the payment details have been updated by the cardholder.
• The endpoint only works for cards with types VIRTUAL, PHYSICAL or TRAVEL
• Allowed values for property terminateCardReason are depending on card type
  • For cards with type PHYSICAL all values are valid. If LOST, STOLEN is provided, the replaced card gets automatically terminated; if DAMAGED or OTHER is provided the replaced card gets terminated only once the newly created card is activated.
  • For cards with type VIRTUAL or TRAVEL only the values STOLEN (for compromised card details) or OTHER are allowed. In both cases, the replaced card gets immediately terminated.

Minor improvements

• We have updated our API lifecycle guidelines

We added a couple of improvements to several parts of our API especially on your possibilities to maintain callback subscriptions.

Callback management

(1) We improved the management of subscriptions/callbacks

• Consumers are now able to edit existing subscriptions simply by calling the respective POST endpoints with the updated payload.
• We are introducing a new endpoint to fetch your current callback configuration: GET api/subscriptions. It returns a list of all active subscriptions.
• Once the cardUpdated callback is sent for card updates (e.g. because the event CARD_DETAILS_CHANGED has happened) and no changes are made to the card limits the limitChange property will be omitted from the payload from now on.

(2) We are introducing the possibility of setting a syncFromDate once you activate organization authorization via POST /organizations/{organizationId}/activate. Once set you will only receive callbacks for business entities with createdAt later than syncFromDate.

• The default setting is the organization's creation date in the Pliants system hence if not set while calling the endpoint you are going to receive all callbacks for all business entities no matter if they occurred before setting up the connection between Pliant and your application.
• If existing authorization is removed (e.g. customer disconnects) and added afterwards again we do use the previously set and already existing syncFromDate if not provided during any (additional) re-activation call.
• If you want to remove the syncFromDate you can simply set it to a date before the organization's creation date.
• We are not re-pushing any historical data. When you set thesyncFromDate in the past, you will only get updates on business entities in the past if the event is happening (and not for events that happened in the past).

Minor improvements

• Previously it was possible to request or issue a card for a member in INACTIVE state. This is not possible anymore. Instead, the API will respond with HTTP status codes 404 and errorCode NOT_FOUND.
• We added cardholderId to transactionUpdated object that is sent for callbacks that can be subscribed via POST /transactions/subscription.

This week we are introducing travel purchasing cards to our API

New card type: TRAVEL

🚧

Important: This card type is disabled per default and each customer and/or partner needs to sign additonal contractual agreements for them to be enabled

Travel purchasing cards are virtual cards designed to be used in travel-related business processes.

From a business perspective travel purchasing cards,

• only work for a specified set of merchants
• are exempt from 3DS

From a technical perspective travel purchasing cards are basically the same as cards with type VIRTUAL.

Changes to the API

We introduced a new ENUM value TRAVEL for property type used in multiple endpoints for card and card requests entities.

List of updated endpoints for cards entity:

• POST /cards/{cardholderId}
• GET /cards/{cardId}
• POST cards/details
• POST /cards/subscription

List of updated endpoints for card requests entity:

• POST /cards/requests
• GET /cards/requests
• GET /cards/requests/{cardRequestId}
• POST /cards/requests/{cardRequestId}/approve
• POST /cards/requests/subscription

To support our embedded partner's mission to build Pliants credit card as a service features seamlessly into their product we are introducing a flexible way to configure email notifications sent out by the Pliant Platform. Additionally, we are adding lots of new Events to our API to enable you to create your own, customized notification framework tailored for each and every one of your customers.

Configuring email notifications

To set up a custom email notification configuration please reach out to your contact at Pliant. We are going to provide all the necessary information to configure email notifications for your organisations accordingly.

You are able to define emails based on

• email template (e.g. monthly limit of organization reacht, card request created ...)
• role of the recipient within pliant (e.g. admin, owner, cardholder ...)
• type of the recipient (embedded vs non-embedded)

You can find more information in our guides section: https://partner.getpliant.com/docs/configure-notifications

👍

To change the configuration of user emails please reach out to us in the dedicated slack channels or via [email protected]

New events

To enable you to create your own notification framework we added the following events to our subscription/callback endpoints

• Callbacks for Organization updates
• Callbacks for Cardholders
• Callbacks for Cards

ORGANIZATION_BALANCE_UPDATED

CARDHOLDER_INVITED
CARDHOLDER_INVITED_NEED_ACTIVATION
CARDHOLDER_INVITED_NEED_REGISTRATION

CARD_BALANCE_UPDATED
CARD_EXPIRED

Please note that CARDHOLDER_INVITED event is generic now and will be sent along with

• CARDHOLDER_INVITED_NEED_REGISTRATION
• CARDHOLDER_INVITED_NEED_ACTIVATION
• CARDHOLDER_REGISTERED

New subscription endpoints

To enable you to create your own notification framework we added the subscription endpoints:

• Callbacks for Card Requests

CARD_REQUEST_CREATED
CARD_REQUEST_APPROVED
CARD_REQUEST_REJECTED

• Callbacks for Card Limit Requests

CARD_LIMIT_REQUEST_CREATED
CARD_LIMIT_REQUEST_APPROVED
CARD_LIMIT_REQUEST_REJECTED

We are introducing a new way to activate physical cards. Instead of dedicated activation codes that need to be added to the card carrier you are able to activate cards via API based on the last four digits of the card's PAN.

Using refNum to activate physical cards

⚠️

To change the way your card manufacturer is preparing cards before shipping them out please consult directly with your contact person there

Previously it has only been possible to activate physical cards with a dedicated activation code that was provided by the card manufacturer when shipping the cards. This special (one-time) activation code needs to be added to the card carrier (e.g. sticker) and is sometimes overlooked by end users.

To address this issue we are enhancing our POST /cards/{cardId}/activate endpoint with a way to activate cards based on the last four digits of the PAN (which in our API we call refNum )

• Added a request body property called activationMethod with allowed ENUM values activationCode & refNum
• Allowed to provide activationCode values with 4 digits (previously 6 digits)

This applies to cards with the following TYPEs:

PHYSICAL
BLACK

Important: Once cards are replaced (currently only supported on the Pliant Platform; soon to be added to Pliant API) the activation method of the new card will match the one used for the replaced card.

We added a couple of improvements to several endpoints

New filter for transaction list and card requests

It is now possible

• to filter transactions based on the query parameter partnerSubmissionStatus for our List of Transactions (GET /transactions) endpoint.
• to filter card requests based on the query parameter type for our List Card Requests (GET /cards/requests) endpoint.

The allowed ENUM values are:

NOT_SYNCED
SYNCED
TEMP_LOCKED
LOCKED

VIRTUAL
SINGLE_USE
TRAVEL
PHYSICAL
BLACK

New endpoint to update cards

We are introducing a new endpoint PATCH /cards/{cardId} that enables to update label OR purpose property based on card type:

New callback in case of changing transaction type

In some (rare) cases merchants do create purchases in the amount of 1.00 EUR instead of card checks. Later on, the transaction type changes from PURCHASE to STATUS_INQUIRY. To better handled such cases we introduced a new TRANSACTION_TYPE_UPDATED event in the transactions callback subscription endpoint: POST /transactions/subscription

Minor improvements

• For POST /cards/{cardholderId} and POST /cards/requests/{cardRequestId}/approve the expiryDate response property returns valid values now (previously responded with NULL).
• Instead of returning HTTP response status code 204 No Content we do return 201 Created including the cardRequestId in the response body when creating card requests using the POST /cards/requests endpoint.
• Fixed a bug where it was not possible to provide NULL value for purpose property when creating card requests using the POST /cards/requests endpoint.
• We tightened the security of the endpoint which allows inviting an owner during onboarding. It's now only possible to call the endpoints POST /cardholders/invite-owner once the organisation is in one of the listed states without getting 403 error.

ONBOARDING_STARTED
ONBOARDING_RISK_AND_COMPLIANCE
ONBOARDING_MANDATES_AND_TERMS
ONBOARDING_WAIT