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.

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.
• 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 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 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 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

📘

This feature is only available in API Version 2.1.0

🚧

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 parameter)
• GET /cards/{cardId} (response)
• POST /cards/details (response)
• POST /cards/subscription (callback payload of cardUpdated object)

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

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 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 the type property to the response and as a query parameter of the GET /cards endpoint.

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

Callback management

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 limitChangeproperty will be omitted from the payload from now on.

Minor improvements

• Previously it was possible to 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 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 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