Benefit Cards are a special type of card offered through the CaaS API. They allow employers to provide recurring, preloaded balances for specific use cases (e.g. meal, mobility, or gift cards). Unlike regular charge cards, benefit cards are load-based and follow distinct business rules for funding and usage.

This guide explains how benefit cards work, how they differ from normal cards, and which API endpoints you need to integrate with.

Key Concepts

• Benefit Cards: cards with a (recurring) preloaded balance (monthly or otherwise). Money not spent may roll over or expire depending on the configuration.
• Dedicated Benefit Card Account: each benefit card has its own account separate from the main card account. Funds are transferred into this account once per month or manually via the API (by loading cards).
• Region Controls (optional)
  • If configured, cards may be restricted to a specific region/ZIP code. Transactions outside this region are declined if a ZIP is present.

Entities

Important Remarks

Benefit Card Lifecycle

1. Configuration – Pliant sets up benefit card configs and enables the feature for the partner
2. Issuance – Partner issues cards with required cardholder data
3. Funding – On the 1st of each month, Pliant batch-jobs load funds if the main account has sufficient balance; manual loads via API are also possible
4. Usage – Cardholder spends within configured limits and optional region restrictions
5. Rollover/Expiry – Depending on the configuration (ACCRUING vs NON_ACCRUING), unused funds roll over or expire

Manual Loading of Benefit Cards

Typically most partners use scheduling loading, hence benefit cards become usable only from the following month (after the first scheduled load). If you don’t want to use the periodic loading feature, just ask us to adjust your card configuration accordingly.

In addition to the automated monthly load, benefit cards can be funded manually via a new endpoint that loads funds to one or multiple benefit cards in a single call: POST /cards/loads. Loads are additive events, not idempotent. Each request creates a new credit event that must be audited.

Request

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

Response

{
  "results": [
    {
      "cardId": "111",
      "status": "load_applied",
      "newAvailableBalance": {
        "value": 200,
        "currency": "EUR"
      }
    },
    {
      "cardId": "222",
      "status": "load_applied",
      "newAvailableBalance": {
        "value": 150,
        "currency": "EUR"
      }
    }
  ]
}

Possible statuses:

• load_applied, load accepted, balance updated
• card_not_found, unknown cardId
• currency_mismatch, load currency does not match the benefit account currency
• limit_exceeded, resulting balance would exceed company limit

Business Logic:

• Endpoint is only valid for benefit cards
• Load currency must match the benefit account currency
• Behavior mirrors scheduled monthly loads
• Funds moved from main → benefit account
• Card history entry written

For full details please refer to the updated API Reference.