Changelog

All notable changes to the Lunar Open Banking API are documented here, organized by API spec version.

Account Information and Payment Initiation API

0.8.0-beta

Account usage field

• usage — a new optional field on the Account object indicating whether the account is owned by a private individual (PRIVATE) or an organisation (ORGANISATION). Omitted when the owner type cannot be determined. Signing baskets and drafts remain in beta and carry over unchanged from 0.7.0-beta.

0.7.0-beta

Transaction enrichment — message, debtor/creditor, account balance, additional information

This release enriches the Transaction object with several new optional fields that bring the Lunar API closer to the NextGen Berlin Group standard and address integration requests from partners.

• message — a free-text payment message associated with the transaction. Sourced per transaction type: the sender note on a domestic credit transfer, the message on a payment or direct debit, the receiver message on an international payment, or the description on Swedish giro/Swish flows. Present when available; omitted otherwise.
• debtor / creditor — structured TransactionParty objects (name, address, account, bic) identifying who funds are debited from and credited to. The nested account carries scheme (IBAN, BBAN, or ACCOUNT_NUMBER) and identification. Direction is determined by the sign of billingAmount: incoming transfers have the counterparty as debtor and the account holder as creditor; outgoing transfers reverse this. Aligns with Berlin Group’s debtorAccount / creditorAccount / debtorName / creditorName shape.
• accountBalanceAfterTransaction — an Amount object with the booked account balance after this transaction settled. Populated for settled transactions; omitted otherwise. Inspired by Berlin Group’s balanceAfterTransaction.
• additionalInformation — a free-form string map for transaction identifiers that don’t fit structured fields. Currently emitted keys: bgNumber, pgNumber, giroNumber, bgIssuer, ocr, swishId. Consumers should treat unrecognized keys as opaque — new keys may be added without a version bump. Modeled after UK OBIE’s SupplementaryData / Berlin Group’s additionalInformation.

All new fields are additive and tagged omitempty — existing consumers that ignore unknown fields are unaffected.

The previously undocumented debtorName string field (which was never publicly released in any portal spec) has been replaced by the structured debtor/creditor model. No consumer impact.

Signing baskets and drafts remain in beta and carry over unchanged from 0.6.0-beta. The previous 0.6.0-beta spec remains selectable in the version dropdown for reference.

0.6.0-beta

Breaking change — draft and signing-basket statuses aligned with payment statuses

This release renames the wire-facing status enums on the draft and signing-basket endpoints so that all three layers (per-draft lifecycle, per-draft basket entry, basket overall) share the same uppercase vocabulary as the underlying payment endpoints. See the cross-layer status mapping section for the full picture.

Per-draft lifecycle on GET /payments/drafts/{type}/{id} (DraftResponse.status):

Per-draft basket entry on GET /payments/drafts/approve/{requestId}/status (DraftApprovalStatus.status):

Basket overall (ApprovalStatus):

In addition:

• paymentId on per-draft basket entries is now present when status is PENDING or COMPLETED (was awaiting_execution or completed).
• expectedExecutionDate is now present only when status is PENDING (was awaiting_execution).
• The per-draft FAILED state remains a side path — when a payment can’t be completed, the draft itself recycles back to CREATED with paymentError populated, ready for retry. Same behaviour, new name.

Roll-out: clean break — no dual-emit / deprecation window. The previous 0.5.0-beta spec remains selectable in the version dropdown for reference.

0.5.0-beta

Beta release — Drafts and Signing Baskets

• Added draft endpoints for SE Bank Giro and SE Plus Giro payments, enabling staged payment preparation where fields can be added incrementally before approval
  • POST /payments/drafts/se-bank-giro — Create a draft. Accepts an optional draftId field — if omitted, the server generates one.
  • GET /payments/drafts/se-bank-giro/{id} — Retrieve a draft
  • PATCH /payments/drafts/se-bank-giro/{id} — Partially update a draft
  • DELETE /payments/drafts/se-bank-giro/{id} — Delete a draft
  • Same set of endpoints for se-plus-giro
• Added signing basket (batch approval) endpoints
  • GET /payments/drafts — List approvable drafts for the current user. Draft summaries include an invalidReason field — a localized string explaining why a draft is invalid (present when isValid is false) — and a paymentError field — a localized string describing why a previous payment attempt failed, present when a draft returns to approvable state after a payment failure, allowing re-approval. Use the X-Language header to control the language.
  • POST /payments/drafts/approve — Batch approve multiple drafts with a single authorization challenge. Accepts a required redirectUrl in the request body and returns an optional authUrl in the response so TPPs can redirect the PSU to complete Strong Customer Authentication, matching the behaviour of single-payment endpoints. After SCA the PSU is redirected back to the supplied redirectUrl.
  • GET /payments/drafts/approve/{requestId}/status — Poll per-draft approval and execution status. Per-draft status is one of pending, approved, awaiting_execution, completed, failed. Each entry carries paymentId once the draft reaches awaiting_execution or completed, an optional expectedExecutionDate (ISO 8601 YYYY-MM-DD) when the executing service has scheduled the payment for a specific date, and a localized errorMessage when failed (controlled by the X-Language header).
• New draft status lifecycle: DRAFT → APPROVING → EXECUTING → EXECUTED (or DELETED)
• New approval status model: created, completed, expired, declined
• Added PENDING and COMPLETED to the SE Bank Giro and SE Plus Giro status enums. Same-day payments now transition AWAITING_APPROVAL → APPROVED → COMPLETED, while future-dated payments transition AWAITING_APPROVAL → PENDING and remain in PENDING until their execution date.

0.4.0

• Added DELETE /payments/se-bank-giro/{id} — Cancel a Bank Giro payment (idempotent, returns 204)
• Added DELETE /payments/se-plus-giro/{id} — Cancel a Plus Giro payment (idempotent, returns 204)
• Added CANCELLED to the SE Bank Giro and SE Plus Giro status enums

0.3.0

• Added SE Bank Giro payment type
  • POST /payments/se-bank-giro — Initiate a Bank Giro payment
  • GET /payments/se-bank-giro/{id} — Retrieve a Bank Giro payment
• Added SE Plus Giro payment type
  • POST /payments/se-plus-giro — Initiate a Plus Giro payment
  • GET /payments/se-plus-giro/{id} — Retrieve a Plus Giro payment

0.2.0

• Added GET /accounts/{accountId}/transactions/{transactionId} — Retrieve a single transaction by ID

0.1.0

Initial release

• Account Information (AISP)
  • GET /accounts — List accounts
  • GET /accounts/{accountId}/transactions — List transactions
  • GET /funds-confirmation — Check funds availability
• Payment Initiation (PISP)
  • POST /payments/domestic-credit-transfer — Initiate a domestic credit transfer
  • GET /payments/domestic-credit-transfer/{id} — Retrieve transfer status
  • POST /payments/dk-payment-slip — Initiate a Danish payment slip
  • GET /payments/dk-payment-slip/{id} — Retrieve payment slip status
  • POST /payments/standing-order — Create a standing order
  • GET /payments/standing-order — List standing orders
  • GET /payments/standing-order/{id} — Retrieve a standing order
  • DELETE /payments/standing-order/{id} — Delete a standing order

Registration API

0.1.0

Initial release

• TPP registration, client management, and OAuth2 token endpoints