Payment API: Unpaid, expectedTs og First-scheduleTypes

Introducing:

  • Payment state: "Unpaid"
  • Payment timestamp: "expectedTs"

Deprecating:

  • The follow Agreement Schedule Types:
    • YearlyFirst
    • HalfyearlyFirst
    • QuarterlyFirst
    • MonthlyFirst
    • WeeklyFirst

During 2026 we will implement a series of backward-compatible optimisations in the Payment API. These improvements aim to simplify maintenance of the source code, ensure stability, and make it easier for new integrators to work with the Payment API.

State: Unpaid

The Payment state: “Unpaid” is assigned to Pending payments that have not been charged three months after dueDateTs, without any error detected.

Common examples are Direct Debit claims with Arion Banki or FI-kort (giro) via Betalingsservice, e.g. FI-kort has been sent by post, but it has not been paid and we have no options to check its status.

The Unpaid state reflects that no further action will be made for this particular payment, and allows for anonymisation which is prohibited Contacts with Pending Payments. However, should the Payment be paid at a later time, the Payment state will be updated to: “Charged”.

No webhook is sent when the state is set to “Unpaid”, as we consider this a non-action.

Timestamp: expectedTs

The new “expectedTs” timestamp indicates when the payment is expected to be processed and is shared across all Payment Types. In practice, this timestamp corresponds to the following for each Payment Type:

  • Single: “chargedTs
  • OneOff: “chargedTs
  • Recurring: “dueDateTs

Our aim is to help analysis and pivot across all Payment Types.

Schedule Types with First

The following existing schedule types are being deprecated in favour of variants without the suffix “First”:

  • YearlyFirst
  • HalfyearlyFirst
  • QuarterlyFirst
  • MonthlyFirst
  • WeeklyFirst

Our aim is to narrows the scope of options for integrators.

The use of “*First” was generally very limited and Agreements with such scheduleTypes have been updated accordingly.