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.

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:

• There is an endpoint to fetch all available custom fields for an organization
• Custom fields can be assigned while issuing a card and can be accessed when fetching the card details.
• Custom fields can be updated for each ...
  • card via the Update custom fields (cards) endpoint.
  • accounting transaction via the Update Custom Fields (accounting transaction).
• You can access the custom fields set for any given accounting transaction.

📘

Only available in v2.1.0

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

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

We have added a new endpoint to directly fetch sensitive card data (PAN and CVV) directly from Pliant. No need to use MeaWallet anymore.

You will find the new endpoint here in our v2.1.0 API specification.

📘

Only available in v.2.1.0 and for companies that are themselves PCI-DSS certified!

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

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:

• 🔗 POST /transaction/details
• 🔗 POST /transactions/subscription

❗️

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.

We are introducing a new entity: Accounting Transactions.

Accounting Transactions

In Pliant it's possible to

• assign accounting-relevant data fields (e.g. G/L accounts, VAT rates...) to a transaction
• and split one transaction into multiple sub-transactions

We do store this information not on the transaction level (transactionId) but on the accounting transaction level (accountingTransactionId). We do start exposing this data in our APIs as well by adding the following endpoints/callbacks:

1. 🔗 POST /accounting/transactions
   Returns accounting transactions for 1-n transactions, cards, cardholders or organizations
2. 🔗 POST /accounting/transactions/subscription
   Available events: ACCOUNTING_TRANSACTION_CREATED & ACCOUNTING_TRANSACTION_UPDATED

Accounting Data fields

In Pliant we do offer multiple tags/attributes that can be first created and later assigned to an accounting transaction:

• G/L Accounts
• VAT Rates
• Suppliers
• Teams (Cost Centers)
• Projects (Cost Units)

Over time we plan to expose the CRUD operations for these accounting data fields. For now we do offer reading, creating, updating and deleting for

• 🔗 Projects (Cost Centers)
• 🔗 Projects (Cost Units)

In addition to that projects can also be restricted to certain teams:

• This can be done by assigning a team to a project via
  🔗 POST /accounting/projects/team/assign.
• There is an endpoint available to unassign a team from a project via
  🔗 POST /accounting/projects/team/unassign
• If no team is assigned to a project it is accessible/visible to all members.

We added the possibility to implement Google Pay and/or Apple Pay for your cards.

Apple Pay / Google Pay Integration

It is now possible for partners to implement Google Pay and/or Apple Pay for their cards in their mobile apps. You can find all the necessary information in this article in our guides section: 🔗Apple Pay / Google Pay Integration.

We are offering a new endpoint that matches the receipt automatically to a transaction.

Receipt Automatching

You are now able to programmatically access our receipt auto-matching feature. There are multiple options/endpoints available:

1. Automatch and attach a file to a transaction: Provide a receipt file (PDF, PNG, JPEG) and we try to find the corresponding transaction for this receipt.
   POST /receipts/automatching
2. Automatch Metadata to a transaction: Provide us with metadata about a receipt and we try to find the corresponding transaction for this metadata. Nothing is attached to the transaction, we just provide a matching transactionId if found. The more data provided, the better the matching result.
   POST /receipts/automatching/metadata

Both endpoints work asynchronously and do start the auto-matching process.

There are two ways to check the result:

1. Query the status of the auto-matching task specified by automatchingTaskId.
   GET /receipts/automatching/{automatchingTaskId}
2. Subscribe to the event RECEIPT_AUTOMATCHING_FINISHED and you'll receive a callback once it is finished.
   POST /receipts/automatching/subscription

More information can be found in our guides section: 🔗 Receipt Automatching

📘

This feature is only available in API Version 2.1.0