Card Account Supersession, Card Account Transfers, Onboarding Submission Updates & More

This release exposes card account supersession, adds transfers between card accounts, introduces a combined create-and-submit endpoint for onboarding submissions, and adds card name fields, an accounting fields endpoint, a payment program endpoint and several callback additions. It also contains corrections to the onboarding submission contract that affect integrations built on the earlier documentation.

At a glance

Breaking changes

Onboarding submission contract corrections

The onboarding submission documentation described several values that the API does not accept. If you built against the earlier documentation, check the following:

• US state values: state on addresses takes two-letter codes (for example NY), not full names (for example NEW_YORK).
• Ownership percentage: ownershipPercentage on UBOs and corporate shareholders is an integer whole percent. Fractional values are rejected.
• entity.otherDescription: removed. It was never accepted.
• Submission status events: SUBMISSION_IN_APPROVAL_PLIANT and SUBMISSION_IN_APPROVAL_BANKINGPARTNER are replaced by SUBMISSION_SUBMITTED, which fires twice. The new detailedStatus field (IN_APPROVAL_PLIANT or IN_APPROVAL_BANKINGPARTNER) tells you which step was reached while status stays SUBMITTED. SUBMISSION_ACCEPTED is listed but not sent today.

Migration: send two-letter state codes and integer ownership percentages, and read detailedStatus instead of subscribing to the two removed event types.

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, including the card account list on organizations.
• 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, GET /api/organizations, GET /api/organizations/{organizationId}

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.

Create and Submit onboarding submission

Validate, create and submit an onboarding submission in a single request.

POST /api/partner/onboarding-submissions/create-and-submit

• The organization must still be in onboarding and must not have a submission yet.
• At least one authorized signatory with signingAuthority SOLE or JOINT must provide person.names.firstName, person.names.surname and person.contact.email. Every other field is optional but validated when present.
• On validation failure nothing is persisted. The response is 422 and message lists each failure as <fieldPath> <ruleCode> <message>.

Fix: create-and-submit no longer returns 403 for newly created organizations before the authorization grant lands.

Optional card name fields for legal representatives

A legal representative whose name does not fit the card can be given a shorter embossed name.

• New fields: person.names.firstNameCard and person.names.surnameCard on authorized signatories, each max 24 characters.
• Behavior: used only when both are supplied. A single card field is ignored and the legal name is used. The legal name is stored unchanged either way.
• Validation: the embossed name (firstName surname or the card pair) must not exceed 24 characters combined. Violations return 422 with rule CARD_HOLDER_NAME_MAX_LENGTH, so the submission is rejected up front instead of failing later.

Update Accounting Fields

Set the subcategory (G/L account), VAT rate and project (cost unit) on a single accounting transaction. Fields you leave out are not changed.

PATCH /api/accounting/transactions/{accountingTransactionId}/accounting-fields

Returns 204. For a transaction that is not split, the accounting transaction id equals the transaction id.

Get Payment Program

Read your own payment program: name, integration model, status and eligibility (allowed countries and currencies with defaults). The program is resolved from your credentials. An empty list means that dimension is not restricted.

GET /api/partner-management/payment-program

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.

Provide Lead fields

POST /api/partner-management/lead accepts four new optional fields: expectedMonthlyTransactionVolume, mainAccountCurrency, customerRelationshipLength (months) and customerAcquisitionChannel (OUTBOUND, INBOUND, REFERRAL, PARTNER, CAMPAIGN). plannedCreditLimit is deprecated, and values sent in it are treated as the expected monthly transaction volume.

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.

Multiple statuses on the cardholder filter

status on GET /api/cardholders can be repeated to return cardholders matching any of the given statuses (INVITED, ACTIVE, DEACTIVATED).

Callback reliability

• The circuit breaker now handles partner 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.

Update partner settings

The endpoint field is deprecated and has no effect. Callback destination URLs are managed through /subscriptions and /subscriptions/bulk-upsert. The response now returns the saved callbackSettings with the client secret redacted (clientSecretSet shows whether one is stored).

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: partner.getpliant.com