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 are exposing our FX fee data now. These enhancements improve transparency and detail for API consumers interacting with foreign exchange rates and fees through our CaaS API.

FX fee on organization & transaction and account entry entity level

• FX Rate Field:

  • Added fx_rate field to the GET /organization endpoint, enhancing organization details by including foreign exchange rate information.
  • Updated the ORGANIZATION_UPDATED callback payload to include the fx_rate field. This field will now be part of the payload when an organization update is triggered, allowing partners to receive real-time updates on FX rates.

• FX Fee Object:

  • Added fx_fee object to the GET /transaction endpoint, providing detailed foreign exchange fee information for transaction details.
  • Introduced the fx_fee object to the GET /account_entry endpoint, specifically for entries where type = TRANSACTION, enabling better visibility of FX fees associated with account entries.

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. More information on the topic of account limits and balanced can be found in this article.

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