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

We improved the way you are able to track the onboarding progress of an organization by adding an additional endpoint and several new callbacks.

Onboarding & Risk status

Sometimes the user who needs to provide data and/or documents during onboarding is not the one who applies/enables the credit card feature in your applications. Previously it was not possible for you to show any kind of information about onboarding progress to your customers.

We do now provide a new endpoint that allows you to fetch details about the onboarding of a specific organization: GET /organizations/{organizationId}/risk.

This enables you to either show information about the onboarding status to your support/ops/sales teams. You can even provide the progress of the onboarding as part of your UI to your customers.

Onboarding Events

Next to the endpoint, we are providing a list of new events that you can subscribe/unsubscribe to by adding or updating your subscriptions for the organization entity:

REPRESENTATIVE_SUBMISSION_STATUS_CHANGED
REPRESENTATIVE_LEGITIMATION_STATUS_CHANGED
DOCUMENT_CUSTOMER_STATUS_CHANGED
DIRECT_DEBIT_STATUS_CHANGED
BANK_CONNECTION_STATUS_CHANGE

All of the above do have eventType, organizationId and statusChange properties in the body of the callback.

• For REPRESENTATIVE_SUBMISSION_STATUS_CHANGED and REPRESENTENTIVE_LEGITIMATION_STATUS_CHANGED we do additionally provide the representativeId.
• For DOCUMENNT_CUSTOMER_STATUS_CHANGED we do additionally provide category.

Please find a sample below:

{
  "eventType": "REPRESENTATIVE_SUBMISSION_STATUS_CHANGED",
  "organizationId": "b1f8e35c-c500-4bbf-aa20-3dc14b83ff19",
  "representativeId": "2acaec98-b337-4006-ba09-a93874d9b338",
  "statusChange": {
    "beforeChange": "INTERNAL_ONLY",
    "afterChange": "INFO_REQUESTED"
  }
}

Important remarks

📘

We do only share any information via endpoint or events if the owner of the organization has agreed to share the onboarding status within Pliant.

❗️

We do never share any personal and/or sensitive information of any of the involved parties nor do we share any details about the requested documents, connected bank accounts or the direct debits.

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.