This release includes improvements to callback visibility, card design support, and extended card state information.

Callback Status Visibility

API consumers can now check if callbacks are activated for their integration.

Endpoint:

• GET /callbacks/subscriptions — Returns the list of active callback subscriptions and now also includes the callbacksEnabled (boolean) flag.

For more information, please check: https://partner.getpliant.com/reference/get-callback-subscriptions.

Card Design Support

A new cardDesignId property has been added to Issue Card endpoints, allowing specification of card designs (i.e., color variants for virtual cards) during card issuance.

Request & Response Changes:

{
  "cardDesignId": "design-uuid-here",
  ...
}

Affected Endpoints:

• POST /cards — Issue Card
• POST /cards/instant — Issue Card (Instant)
• POST /cards/instant/pci — Issue Card (Instant as PCI-DSS)

For more information, please check: https://partner.getpliant.com/reference/issue-card

Extended Card State Information

To provide better visibility into why a card is in PENDING status, we have added a new pendingDetails property.

New Property:

• pendingDetails (string) — The detailed reason for a card's pending state. Possible values:
  • PENDING_ACTIVATION
  • PENDING_ISSUANCE
  • PENDING_REGISTRATION
  • PENDING_VALIDITY
  • PENDING_SANCTION_SCREEN
  • PENDING_INFORMATION

This field is only populated when status is PENDING (or one of the deprecated PENDING_* statuses) and will be null for all non-pending statuses.

Deprecation Notice:

The granular PENDING_* status values (e.g., PENDING_ACTIVATION, PENDING_INFORMATION) are now deprecated. Please migrate to using the status: PENDING combined with pendingDetails for the specific reason. These deprecated statuses will be removed with the next API version.

Affected Endpoints:

• POST /cards/details — Card Details
• Card-related callbacks

For more information, please check: https://partner.getpliant.com/reference/get-multiple-card-details.

This release includes improvements to callback visibility, card design support, and extended card state information.

This changelog documents card-related API improvements including new properties, callback triggers, and validation enhancements.

Card Activation Method Property

A new activationMethod property has been added to the card entity based on the card manufacturer.

Response Changes:

The card entity now includes:

{
  "status": "PENDING_ACTIVATION",
  "activationMethod": "refNum" | "activationCode" | null,
  ...
}

Affected Endpoints:

• GET /cards/{id}
• GET /cards
• Card-related callbacks

For virtual cards, or cards where activation does not apply, this value is set to null. For more information, please check: https://partner.getpliant.com/reference/activate-physical-card

Small Improvements / Bugfixes

• The CARD_DETAILS_CHANGED callback is now triggered when a card's cardholder is changed via POST /cards/platform-fee/{id}/reassign
• Enhanced validation to prevent benefit card issuance or requests with invalid configuration properties like e.g. limit or limitFrequency != TOTAL.

🚧

Changes effective the 30.01

We are introducing quotas for Auth0 Access Tokens.

Enforcement

Quotas are now enforced for new API consumers upon activation.

Monitoring Usage

Specific limits vary based on account type and program requirements.

Please refer to the API response header to monitor the available tokens and remaining quota for your specific use case.

For a comprehensive breakdown of our rate-limiting logic, please visit the Access Token Request Quotas guide.

Signed callbacks and redirects (Ed25519)

Pliant now cryptographically signs both callbacks (webhooks) and partner authorization redirects using Ed25519, enabling partners to verify authenticity and protect against tampering and replay attacks.

Callback authenticity

• All callbacks include the standardized headers webhook-id, webhook-timestamp, and webhook-signature
• Signatures follow the Standard Webhooks Signature Scheme
• The signature is calculated over
  <webhook-id>.<webhook-timestamp>.<raw HTTP payload>
• Each payment program has its own signing key
• Public keys are available via /api/partner-management/signing/jwks.json
• Partners can cache keys long-term; key rotations will be announced in advance

📘 Full implementation details and verification examples are available here: Callback authenticity

Redirect signing (partner authorization flow)

• Redirects from Pliant to partner apps are now signed
• The signature covers
  <t>.<partnerId>.<organizationId>
• A timestamp (t) is included to mitigate replay attacks
• Partners should validate timestamp tolerance and verify the signature using the program’s public key
• Ensures redirects originate from Pliant and parameters were not modified

📘 Full implementation details and verification examples are available here: Integration initiated from Pliant (Signed redirects)

We’ve released an update that allows consumers to subscribe to callback events using multiple callback URLs.

(1) Add Multiple Callback Subscriptions

New Endpoint: POST /subscriptions/bulk-upsert

Remarks:

• This creates multiple callback subscriptions in a single request;
• The response includes both newly created subscriptions, and existing subscriptions that already match the same eventType + callbackUrl.
• Multiple subscriptions per eventType are supported as long as callbackUrls differ.
• If a subscription with the same eventType + callbackUrl already exists, it is not modified but is still returned in the response.
• Only subscriptions included in the request are affected; all other existing subscriptions remain unchanged.
• A maximum of 42 subscriptions per eventType is allowed.

(2) Delete Callback Subscription:

New Endpoint: DELETE /subscriptions/id

Remarks:

• Deletes a callback subscription by its UUID.
• Returns 204 No Content upon successful deletion.

We’ve introduced a new set of Card Account management endpoints that provide more control and visibility over your customers card accounts.

• Create Card Accounts (POST /card-accounts)
  Create new card accounts programmatically.
• Update Card Accounts (by ID) (PATCH /card-accounts/:id:)
  Update details of an existing card account.
• Deactivate Card Accounts (by ID) (POST /card-accounts/:id:/deactivate) Deactivate a specific card account by its identifier.
• Get Available Card Account Currencies (GET /card-accounts/available-currencies) Retrieve a list of currencies supported for card account creation based on organization setup (banking partner, issuer ...)
• Card Account Summary (GET /card-accounts/summary) Returns an aggregated summary of all active card accounts for the given organization. This includes the total count of card accounts, overall available and credit limits, as well as breakdowns by currency.
• Additional Card Account Callbacks New webhook events are available for card account lifecycle updates:

CARD_ACCOUNT_ADDED
CARD_ACCOUNT_STATUS_CHANGED

(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