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

We added new properties to the response object of the Organization Details endpoint.

Organization Details

We have added additional properties to the endpoint GET /organizations/{organizationId}. This information is beneficial if you want to

1. allow users to access data about their bank account (processingAccount)for top-up payments (relevant for pre-funded organizations only)
2. check what organization name is printed on the physical cards (tradeName) in cases where either the organization's name is too long (isCompanyNamePrintable == true) or customers simply opted to choose another company name to be printed on the cards.

💡Additionally we fixed a bug where the paymentFrequency property was set to MONTHLY for organizations with accountType == PREFUNDED

Here is the list of all properties that have been added to the response:

  "nationalRegisterCourt": "string",
  "nationalRegisterId": "string",
  "nationalRegisterType": "string",
  "tradeRegisterNumber": "string"
  "vatId": "string",
  "billingEmail": "string",
  "billingAddress": {
    "id": "string",
    "type": "BILLING",
    "country": "string",
    "city": "string",
    "postalCode": "string",
    "street": "string",
    "streetName": "string",
    "streetNumber": "string",
    "streetAdditional": "string"
  },
  "deliveryAddress": {
    "id": "string",
    "type": "BILLING",
    "country": "string",
    "city": "string",
    "postalCode": "string",
    "street": "string",
    "streetName": "string",
    "streetNumber": "string",
    "streetAdditional": "string"
  },
  "isCompanyNamePrintable": boolean,
  "processingAccount": {
    "beneficiary": "string",
    "bankName": "string",
    "iban": "string",
    "bic": "string"
  }

We added some minor improvements in the domains of cardholder and card limit endpoints

Cardholder status

Previously the cardholder status was not exposed. We improved it by:

1. adding the status property to query params & response body of GET /api/cardholders
2. adding the status property to the response body of GET /api/cardholders/{cardholderId}
3. adding a new callback CARDHOLDER_INVITED to POST /cardholders/subscription which is triggered when a member is invited.
4. extending the Callback object cardholderUpdate with status property

Possible ENUMs are:

INVITED
ACTIVE
DEACTIVATED

Card limit changes

We do now provide more granular information about card limit changes. So whenever one of the listed properties of a card is updated we trigger the CARD_LIMIT_CHANGED callback (if setup via POST /cards/subscriptions).

transactionLimit
monthlyLimit (this one is deprecated)
limit
limitRenewFrequency

We provide a new property called limitChange which includes the previous and the new values so you can easily build e.g. notifications on top of it. Please find an example below:

{
  "eventType": "CARD_LIMIT_CHANGED",
  "cardId": "...",
  "organizationId": "...",
  "cardholderId": "...",
  "type": "VIRTUAL",
  "status": "ACTIVE",
  "label": "Test",
  "limitChange": {
    "beforeChange": {
      "transactionLimit": {
        "value": 4200,
        "currency": "EUR"
      },
      "limit": {
        "value": 4200,
        "currency": "EUR"
      },
      "limitRenewFrequency": "QUARTERLY"
    },
    "afterChange": {
      "transactionLimit": {
        "value": 8400,
        "currency": "EUR"
      },
      "limit": {
        "value": 8400,
        "currency": "EUR"
      },
      "limitRenewFrequency": "QUARTERLY"
    }
  }

We added the card limit frequencies feature to our API product.

📘

This topic is especially relevant for embedded partners!

What is it about?

We added something new to our API: card limit frequencies. With this feature, you are able to set a card limit frequency while creating cards and card requests as well as fetching data regarding card limit renewal when reading card data. You can even change the card limit frequency for existing cards.

What does it mean? Per default credit cards do revert back to their limit each calendar month. With card limit frequencies you are able to control if and when a card limit renews. There is even a way to define a total limit which is never gonna be renewed at all.

How to use it?

You do have a possibility now to define a card's limit frequency when...

• ... issuing a card (Issue card) or changing card limits (Update Card limits) via limit and limitRenewFrequency properties.
• ... requesting a card (Create card request) via requestedLimit and limitRenewFrequency properties.
• ... approving a card request (Approve Card Request) via approvedLimit and limitRenewFrequency properties.

For limitRenewFrequency you can choose between:

• MONTHLY - card limit (set via limit property) refreshes every calendar month (default value)
• QUARTERLY - card limit refreshes every calendar quarter
• ANNUAL - card limit refreshes every calendar year
• TOTAL - card limit does not refresh. Once the amount is spent the card is not usable anymore.

To keep track of this for existing and new cards we added a couple of new properties to our Card Details and Card Request Details endpoints.

• limitRenewFrequency
• requestedLimit (only for Card Request Details)
• limit (only for Card Details)
• limitPeriodEnd (only for Card Details)
• limitRenewDate (only for Card Details)

❗️

With this feature we do put the monthlyLimit property to deprectated status. For now it returns the card limit (independent of the card limit frequency). As this is kind of misleading we ask you to build or adapt your implementation based on the new limit property.

Important notes:

• If you modify the card limit frequency it affects cards immediately meaning that if an existing card is changed from QUARTERLY to MONTHLY the limit will be renewed with the next calendar month already!

We have been adding new endpoints for credit card statements based on calendar month as well as additional properties/ENUMs for transactions entity: booking date (bookedAt) and BOOKED as value for property (status).

Bills are statements now

In the last couple of weeks, we reworked our billing logic under the hood completely.

This allows us to enable billing periods based on the calendar months, and the statement PDFs generated at the end of the billing periods will cover the transactions and payments from the 1st of the month to the end of the month.

Accompanying those improvements in our backend we added three new endpoints to get data for your customer's credit card statements:

• List of statements
• Statement details
• Statement PDF

In addition to that, you are able to subscribe to and unsubscribe from the available events for statement callbacks:

• Create Callback (https://partner.getpliant.com/reference/createstatementsubscription-1)
• Delete Callback (https://partner.getpliant.com/reference/removestatmentsubscription-1)

Booking date

In addition to the new endpoints, we added data about the booking date of a transaction, which is going forward the date that defines to which statement period the transaction is being assigned to.

We

• added the property bookedAt to response object of Transaction details
• added a new ENUM value BOOKED to status property in response object of Transaction details
• trigger the event TRANSACTION_STATUS_CHANGED once the status of a transaction is changed to BOOKED
• added a new ENUM value BOOKED to the status filter in the request params of List of transactions

Migration

As this is something that has been requested a lot, we aim to migrate all organizations in 01/2023. What does migration mean?

(1) For migrated organizations ...

• 24 Dec - 23 Jan will be the last _irregula_r billing period for the organizations
• Just after this period, we’ll have a transition (stub) billing period between 24 Jan - 31 Jan. And on the 24 of Jan, the organizations will start seeing a new Billing page in our system
• Starting 1 Feb, the organizations will have a calendar month-based billing period

(1) The following endpoints will not work anymore:

• List of bills
• Bills details
• Bills PDF

We have already marked them as deprecated. If you are currently implementing our partner API please use the now already available statement endpoints listed above.

(2) Transactions will be included in the monthly statements based on their booking date and the properties mentioned above will be populated accordingly.

❗️

If you are currently using any of the endpoints above or are currently in the process of implementing them please let us know (via your partner manager) if you are able to reflect the changes in your systems until 6th of January.

We simplified the way how to create mock transaction in our sandbox environment by adding an official endpoint POST /test-data/transactions.

More information on how to use it can be found here.

For our embedded partners it is now possible to create leads for Pliants onboarding team programmatically via our endpoint: POST /partner-management/lead. Please contact your partner management before starting to use it in production.