Card Account Supersession, Card Account Transfers, Callback Log & Resend

This release exposes card account supersession, adds transfers between card accounts, and adds the callback log and resend endpoints, plus a set of callback, field and enum additions.

At a glance

Type	Change	Affected area
Deprecation	`cardholderType` replaced by `membershipType`	Card issuing
New	Card account supersession and `CARD_REASSIGNED` callback	Card accounts, callbacks
New	Transfers between card accounts	Card accounts, callbacks
New	Search, read and resend callbacks	Callbacks
New	`acceptanceMethod` on transactions	Transactions, callbacks
New	`STATEMENT_UPDATED` when a statement closes	Callbacks
New	`PAY_IN` payment type	Payments
Improvement	`membershipType`, `state` on cardholder addresses, Hungarian	Cardholders, cards
Improvement	Callback reliability	Callbacks

New features

Card account supersession

A card account can be replaced by a successor card account. The old one stays readable and keeps its history.

New status: SUPERSEDED on card accounts.
New fields: supersededBy (id of the successor), supersedes (id of the predecessor) and supersededAt. All are null when not applicable.
New callback: CARD_REASSIGNED fires once per card that moves to the successor, with cardId, organizationId, previousCardAccountId, cardAccountId and reassignedAt. The card itself is unchanged. If you store a card to card account mapping, update it on this event. Subscribe via the existing CardSubscriptionRequest.
Status callbacks: a change to SUPERSEDED arrives as CARD_ACCOUNT_STATUS_CHANGED and carries supersededBy and supersededAt.
Constraints: no new cards, payments or payouts can be created on a superseded card account.
History: statements, payments and account entries keep the card account id they were booked on. To list across the switch, query both the superseded id and its supersededBy.

Affected endpoints: GET /api/card-accounts, POST /api/card-accounts, GET /api/card-accounts/{cardAccountId}, PATCH /api/card-accounts/{cardAccountId}, POST /api/card-accounts/{cardAccountId}/deactivate

Transfers between card accounts

Move money between two card accounts of the same organization, in the same currency.

POST /api/card-accounts/transfer

Required body fields: organizationId, sourceCardAccountId, moneyToSend, targetCardAccountId, moneyToReceive. The request returns 202 with an internalTransferId. Transfers are processed asynchronously.

New callbacks: CARD_ACCOUNT_TRANSFER_COMPLETED and CARD_ACCOUNT_TRANSFER_FAILED fire once a transfer reaches a final status, with internalTransferId, sourceCardAccountId, targetCardAccountId, organizationId, status and createdAt. Subscribe via the card account subscription.

Callback log and resend

Investigate and recover missed callbacks yourself.

GET  /api/callbacks
GET  /api/callbacks/{callbackId}
POST /api/callbacks/resend

GET /api/callbacks lists every callback Pliant produced for you, whether it could be delivered or not, with status and metadata. Filter by organization, entity ids and more.
GET /api/callbacks/{callbackId} returns the payload of one callback.
POST /api/callbacks/resend re-triggers delivery for 1 to 1000 callback ids. It returns 202 and delivery runs through the normal pipeline with retries and back-off. The request is rejected with 403 if any id is unknown or outside your scope.

Transaction acceptance method

See how a card was presented at the point of sale.

New field: acceptanceMethod (ONLINE, MOBILE_WALLET, MANUAL_ENTRY, CONTACTLESS, CHIP_DIP, NOT_AVAILABLE, MAGNETIC_STRIPE, OTHER). It is null for historical transactions.

Added to: the authorization, confirmation and status changed transaction callbacks and POST /api/transactions/details.

Statement close callback

STATEMENT_UPDATED now also fires when a statement closes (isClosed changes from false to true). Previously a close could not be observed through callbacks.

New payment type `PAY_IN`

PAY_IN is an inbound transfer credited from a third-party sender. It is a new value for the payment type and for the type filter on GET /api/payments. Add it to any strict enum handling.

Improvements

Cardholder membership type

Cardholders created during card issuance now take membershipType instead of cardholderType:

STANDARD (default): the cardholder receives an invitation to register and uses the Pliant web app according to their role.
LIMITED: no registration. The cardholder accesses cards through access links, and the GUEST role is assigned automatically.
EMBEDDED: no invitation email. You obtain acceptance of the terms and verify the phone number.

LIMITED and EMBEDDED must be requested explicitly. cardholderType is deprecated but still accepted (EMBEDDED maps to EMBEDDED, NON_EMBEDDED to STANDARD) and is ignored when membershipType is set. sendInvitationEmail is removed from the documentation. It had no effect, so please stop sending it.

Affected endpoints: POST /api/cards, POST /api/cards/instant, POST /api/cards/instant-pci

State on cardholder addresses

The optional state field is now available on deliveryAddress and personalAddress for cardholder invites, registration, updates and card issuance with a new cardholder.

Affected endpoints: POST /api/cardholders/invite, POST /api/cardholders/register, PATCH /api/cardholders/{cardholderId}, POST /api/cards, POST /api/cards/instant, POST /api/cards/instant-pci

Hungarian language

hu is now a supported cardholder language on invite, register, update and card issuance.

Callback reliability

The circuit breaker now handles endpoints that are only partially available.
Callback publishing and composite callback retries back off between attempts instead of retrying at a fixed interval.
Invalid enum values in a request now return an error message listing the accepted values.

Fixes

Fixed duplicate callback deliveries when callback publisher runs overlapped.
Receipt PDF endpoints now return 404 instead of 500 when the receipt does not exist.

Docs: customer-api.getpliant.com