We've introduced the Card Copilot feature, enabling organizations to share travel purchasing card access with multiple users. Copilots have full card privileges including viewing details, managing settings, and making transactions.

What's New

• Card Sharing: Grant full card access to users beyond the original cardholder
• Team Support: Assign entire teams as copilots for shared departmental cards
• Audit Trail: All copilot activities are tracked for compliance and security
• Seamless Transfers: Transfer card ownership between copilots when needed

Getting Started

1. Enable: Activate the module via Modules page (owner/admin only)
2. Assign: Add copilots when issuing cards using the copilots parameter in Issue Card endpoints
3. Manage: Update copilots anytime via Update Card Copilots
4. Transfer: Allow copilots to claim cards using Claim Card As Copilot

API Updates

• Issue Card endpoints now accept the copilots parameter with cardholderIds and/or teamIds
• New endpoints:
  • Update Card Copilots
  • Claim Card As Copilot

📘

Note

This feature is exclusive to Travel Purchasing Cards and requires Module activation

What changed?
We’ve updated the expected audience value used when authenticating with our API on the sandbox environment.

Previous value:
audience: api.staging.v2.infinnitytest.com/api/integration

New value:
audience: api.staging.infinnitytest.com/api/integration

Impact:
Make sure your token’s audience claim now matches the updated value above. This change ensures proper validation against our sandbox environment.

Reference:
Authenticated API Usage – Pliant Partner Docs

❗️

This change applies only to sandbox environments and does not affect production.

We've introduced two new card limit renewal frequency options that can be used when issuing cards:

• DAILY - Card limits reset on a daily basis
• WEEKLY - Card limits reset on a weekly basis

Example Usage

When creating a card, you can now specify:

{
  "limitRenewFrequency": "DAILY"
}

or

{
  "limitRenewFrequency": "WEEKLY"
}

Backwards Compatibility

This change is fully backwards compatible. Existing card limit renewal frequencies remain unchanged and continue to function as before.

We have added the cardAccountId property to the following event types:

Cards

CARD_CREATED
CARD_ISSUED
CARD_DETAILS_CHANGED
CARD_STATUS_CHANGED

Transactions

TRANSACTION_CREATED
TRANSACTION_UPDATED

Statements

STATEMENT_GENERATED
STATEMENT_UPDATED

We introduced two new endpoints.

Deactivate Organization Authorization

This endpoint completes the existing "Activate Organization Authorization" and will enable you to reset and organization authorization when needed.

Redeem Cashback

The following endpoint will enable a specific organization to redeem the accumulated cashback (totally or partially), completing the "cashback flow" together with the existing endpoints.

We have added further type<>status combinations for our mock service in the sandbox environment. Changes visible here.

We have made small improvements to the transaction, statements and card account entities.

Set receiptNeeded flag on on transaction level

We have added an endpoint that allows to manage the necessity to provide receipts within the Pliant platform (web apps, mobile app). Its now possible to turn receiptNeeded property to false on transaction level allowing for some automations based on e.g. card or merchant level. As API consumer you can now turn off receipts for specific merchants or cards. The endpoint is documented here: PATCH /transactions/{{transactionId}}/receiptUpload.

Balance for each card account

Previously the balance property has been only available on organization level. We have now added it to the card account entity. It can be accessed via this endpoint GET /card-accounts.

Related transactions for statement entity

Each statement has a 1:1 relationship to account entries. It is now possible to fetch all account entries for a given statementId. We extended the existing endpoint GET /statements/{{statementId}} to fetch the details of a statement with the relatedTransaction property.

New custom names character length

We are improving our cards service adjusting the maximum characters of customFirstName and customLastName to a total of 100 (from the current 25).

This change will be especially relevant for travel consumers.

Additional payment webhook

We introduced a new webhook, PAYMENT_READY. API Reference

With this new webhook consumers will be able to identify when a bill payment is complete (= no more transactions will be added to that payment).

We introduced a new endpoint to retrieve account entries for a set organization. Account entries are basically all movements of a card account. The endpoint will enable you to fetch booked account movements and provide detailed account informations, together with the statements endpoint.

• GET /account-entries will return the movements as specified
• POST /account-entries/subscription to subscribe to the related ACCOUNT_ENTRY_CREATED event. The response payload of the callback will be the same of the GET endpoint above

We are introducing a way to retrieve the statement CSV (helpful for reconciliation). In addition to that, we added a new request property for deactivating cardholders and a new callback that is fired once a card is shipped by one of our card manufacturers.

Statement CSV

Until know we only exposed the monthly statement PDF including all the account movements (we call them "account entries") like credit card transactions, bill payments, direct debit reversal fees and so forth. We are now adding an endpoint that allows fetching the so called statement CSV. Usually this file is attached to the monthly billing email (next to the statement PDF) but can also be downloaded for each month using Pliant UI.

To access the file:

1. Call POST /statements/csv to trigger the file creation job for the specified organization, card account and date period.
2. You will receive a callback of type STATEMENT_CSV_DOWNLOAD_READY once the exported CSV file is ready. Do not forget to subscribe to the callback upfront! Otherwise this endpoint returns an error.
3. Fetch the actual file via the URL that is provided in statementFileUrl. This URL is valid for at least 1 week. After that, the file might not be available anymore. The pattern of this URL may change at any time, so do not rely on the structure of the URL. Every time you receive the callback, just use the provided URL in the callback to download the file.

Remarks to the business logic: You can specify start and end dates. In the Pliant application, for all completed months, these dates default to the first and last day of the month. For the ongoing month, the start date defaults to the first day of the month, and the end date is set to the current day.

Deactivate cardholder

It was possible for a long time already to deactivate cardholders by calling DELETE /cardholders/{cardholderId}.

Sometimes there is the business need to deactivate a cardholder and re-invite the cardholder with the same username (email address). This is why we are adding an optional suffix parameter when calling the above mentioned endpoint that allows API consumers to alter the username by adding a suffix like +deactivated to the email address that is stored on the platform.

Business logic:

• If no suffix is applied the cardholder will be deactivated without any change of the username
• If the endpoint is called for already deactivated cardholders the suffix will be applied as well.

Minor improvements

• We're introducing a new event: CARD_SHIPPED. This event will be triggered when we receive confirmation from our card manufacturers that a physical card has been successfully shipped. Please note that this event is applicable only for cards designated as PHYSICAL and will not be triggered for any other card types. The payload is re-using the cardUpdate object described in our API reference for card entity.
• We added the cardId to the payload of CARD_REQUEST_UPDATED callback that is triggered by the following events: CARD_REQUEST_CREATED, CARD_REQUEST_APPROVED & CARD_REQUEST_REJECTED.