Changelog
SupportAPI StatusSubscribe To Updates
Start typing to search…

Quality of life improvements II

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:

❗️

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.

Accounting Transactions

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

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

Tokenization/Provisioning of cards

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.

Automatch receipts

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

Granular onboarding status

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.

Status page

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.

Detailed card status

🚧

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

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

Card limit requests

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:

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

Update partnerSubmissionStatus of multiple transactions

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.

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.

Replace cards

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