(1) Added Business Development Manager Fields to Create Lead Endpoint

We’ve introduced two new properties to include details about the account’s respective Business Development Manager when creating a lead. This enhancement helps our team efficiently reach out and resolve any questions regarding new leads.

  "partnerContact": {
    "name": "Luke Skywalker",
    "email": "[email protected]"
  }

(2) New Card Control: Acceptance Method

A new card control has been added for specifying the card’s acceptance method. It supports multiple enum values and can be configured during card issuance or updated later as needed.

    "cardControls": {
        "acceptanceMethods": {
          "restriction": "ALLOWED",
          "type": "ACCEPTANCE_METHOD",
          "values": [
              "MAGNETIC_STRIPE",
              "MOBILE_WALLET",
              "ONLINE"
        	]
    }

This release introduces full lifecycle management for custom fields and options, adds support for SELECT field types, and extends card request APIs and webhooks with customFields capabilities.

Details

• Custom Field Management Endpoints New endpoints to manage custom fields and their options:

  • Create, update, and delete custom fields
  • List, create, update, and delete custom field options

• Callbacks Added callback support for:

  • Custom Fields
  • Custom Field Options

• New Field Type Support Added support for custom fields of type SELECT in the CaaS/Pro API layer for:

  • Cards
  • Accounting transactions

• Card Request Enhancements Added support for custom fields (independent of text) in:

  • Card Request endpoints
  • Card Request webhook

We are introducing support for Benefit Cards in the CaaS API. This release adds new properties to card configs, card accounts, and cardholder endpoints, introduces region-based controls, and updates the issuance and funding logic when benefit cards are used. Please review the changes below to ensure smooth integration with the updated API.

Changes of existing endpoints/webhooks

Card Configs

• New properties on /get-available-cards:
  • card_properties.funding_type
    • CHARGE – normal non-benefit card
    • LOAD_BASED_ACCRUING – unused funds roll over
    • LOAD_BASED_NON_ACCRUING – unused funds expire end of month
  • card_properties.load_based_settings
    • Defines load config for benefit cards
    • Example:
      JSON

      {
        "fixedAmount": { "amount": 50, "currency": "EUR" },
        "fixedFrequency": "MONTHLY"
      }

  • card_properties.expiry_periods_in_months
    • Defines expiry periods
    • Defaults: 36 months for load-based types and a range of values for other types

Card Accounts

• New property on /get-card-accounts:
  • benefitCardAccount

Cards

• Extended fields on /get-multiple-card-details:

  • fundingType
  • nextLoadDate

• Issuing cards (/issue-card, /issue-card-instant, /issue-card-instant-with-pci):

  • For benefit cards:
    • limit and transactionLimit must be 0 EUR
    • limitFrequency must be set to TOTAL
    • validFrom, validTo & validTimezone must be provided

You can either provide this date before issuing any benefit cards, or issue cards for cardholders who don’t yet have this information. In the latter case, the cardholder must add it later via the API, the Pliant UI, or at any other time. Once the required data is provided, all pending cards will be automatically issued.

Transactions

• New property on /transactions/details:
  • personal

Payments

• When benefit card accounts are funded from the main account, payments are marked as INTERNAL_TRANSFER
• Documentation clarified on /get-payments-detail

Cardholders

• Updated endpoints to support new cardholder data fields (personal/delivery address, nationality, birthdate):
  • /get-cardholder-details → show new fields
  • /update-cardholders → allow editing new fields
  • /register-cardholders & /invite-cardholders → allow setting new fields

You can either provide this date before issuing any benefit cards, or issue cards for cardholders who don’t yet have this information. In the latter case, the cardholder must add it later via the API, the Pliant UI, or at any other time. Once the required data is provided, all pending cards will be automatically issued.

Important Remarks

• Benefit cards are only available after Pliant activates them for your accounts (card configs + feature module)
• There is a dedicated card account per benefit card which is not visible in the UI
• Benefit cards load monthly on the 1st via automated job if scheduled loading is enabled
• Requires sufficient main account balance; otherwise, no funds are transferred
• Load amount = number of active benefit cards × configured load amount
• Optional region-based controls:
  • If ZIP present → validated against allowed region (declined if outside)
  • If ZIP missing → transaction accepted

New endpoint

Load Benefit Cards

POST /cards/loads

• Purpose: Allows you to load funds onto benefit cards manually.
• Why POST (not PUT): Loads are additive events, not idempotent state changes. Each request creates a new credit event that must be book-kept and audited.

Request (batch-friendly)

[
  {
    "cardId": "111",
    "load": {
      "amount": { 
        "value": 100,
        "currency": "EUR"
      }
    }
  },
  {
    "cardId": "222",
    "load": {
      "amount": { 
        "value": 50,
        "currency": "EUR"
      }
    }
  }
]

For details please check out our dedicated guide for benefit cards.

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.