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.12.0

deleted flag and attachments on get-by-id

• The GET /accounts/{accountId}/transactions/{transactionId} endpoint now returns a TransactionDetail object — a full Transaction plus one extra, always-present field:
  • deleted — a boolean that is true when the transaction has been deleted and no longer appears in the transaction lists, false otherwise. This lets consumers detect a pending transaction that later failed (a declined or reversed authorization) and dropped out of both the flat list and the Transactions v2 pending/posted lists, rather than waiting for it to (never) reappear. See Detecting deleted transactions.
• attachmentIds is now populated on the get-by-id endpoint too (previously only on the list endpoints), with the same rules — omitted when the transaction has no attachments. See Attachments.
• The deleted field appears only on the get-by-id endpoint; the list endpoints keep returning the unchanged Transaction object without it.

All changes are additive — existing consumers that ignore unknown fields are unaffected. The previous 0.11.0 spec remains selectable in the version dropdown for reference.

0.11.0

Transactions v2 — pending/posted split with cursor pagination

• Added GET /v2/accounts/{accountId}/transactions, which returns transactions split into two lists following the nextgen standard instead of a single flat list:
  • pending — transactions in status authorization, filtered and ordered on transactionTime.
  • posted — settled (“booked”) transactions in status financial, filtered and ordered on postingTime.
• Pagination is opaque cursor-based: the response returns a nextCursor; pass it back as the cursor query parameter (with the same from/to/limit) to fetch the next page. Pages never overlap, so no client-side de-duplication is required. The shared limit applies to each list independently.
• See Transactions v2 for the full reference. The existing flat GET /accounts/{accountId}/transactions endpoint is unchanged.

Transaction attachments

• Added read-only endpoints exposing the attachments a user has added to a transaction as signed download URLs:
  • GET /accounts/{accountId}/transactions/{transactionId}/attachments — list all attachments for a transaction.
  • GET /accounts/{accountId}/transactions/{transactionId}/attachments/{attachmentId} — get a single attachment.
• Each Attachment carries attachmentId, fileId, an optional mimeType, and a signed downloadUrl whose lifetime is owned by the storage service. Missing, inaccessible, and not-yet-processed attachments all return the same 404. See Attachments.

New attachmentIds field on transactions

• attachmentIds — a new optional string[] on the Transaction object listing the IDs of attachments a user has added to the transaction. Populated on the transaction list endpoints and omitted when there are no attachments. Feed these IDs into the Attachments endpoints to download the files.

All changes are additive — existing consumers that ignore unknown fields and paths are unaffected. The previous 0.10.0 spec remains selectable in the version dropdown for reference.

0.10.0

Card transaction enrichment — entry mode, wallet, ATM, location

This release enriches the cardTransactionInfo object on card Transactions with several new optional fields, surfacing card and location data already present on the transaction.

• cardEntryMode — how the card credentials were captured: chip, contactless, magneticStripe, manual, or merchantInitiated. Omitted when the source data does not specify an entry mode.
• walletProvider — the digital wallet used when the card was tokenized: applePay or googlePay. Omitted when the payment was not made via a digital wallet.
• isAtm — true when the card transaction took place at an ATM. Omitted when the source data does not indicate an ATM transaction.
• merchantLocation — structured merchant address with optional city and country (ISO 3166-1 alpha-2). Populated alongside merchantName/merchantCategoryCode when available. Aligns with Berlin Group’s cardAcceptorAddress.

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

See the Accounts API — Card transaction info section for the full field reference and an example. These are enrichment fields and follow the same eventual consistency behaviour as other optional transaction fields.

Direct domestic credit transfer initiation remains deprecated

• POST /payments/domestic-credit-transfer continues to be marked deprecated (since 0.9.1) and is scheduled for deletion in Q1 2027. See Migration from direct DCT to drafts for field mapping and flow changes.

0.9.1

Direct domestic credit transfer initiation deprecated

• POST /payments/domestic-credit-transfer is marked deprecated in the OpenAPI spec and scheduled for deletion in Q1 2027. New and existing integrations should switch to the draft flow — see Migration from direct DCT to drafts for field mapping and flow changes. The draft flow supports staged payment preparation, validation feedback before approval, and improved payment error handling with re-approval. GET /payments/domestic-credit-transfer/{id} is unchanged and remains the endpoint for retrieving payment status after draft approval.

0.9.0

Domestic Credit Transfer drafts

• Added draft endpoints for Domestic Credit Transfer payments, enabling staged payment preparation where fields can be added incrementally before approval
  • POST /payments/drafts/domestic-credit-transfer — Create a draft. Requires draftId and name.
  • GET /payments/drafts/domestic-credit-transfer/{id} — Retrieve a draft
  • PATCH /payments/drafts/domestic-credit-transfer/{id} — Partially update a draft
  • DELETE /payments/drafts/domestic-credit-transfer/{id} — Delete a draft
  • DELETE /payments/drafts/domestic-credit-transfer/{id}/payment — Cancel an in-flight payment linked to the draft (idempotent)
• Draft fields use domestic-credit-transfer-specific names (senderAccountId, receiverAccountBban, receiverName, senderMessage, shortReceiverMessage, executionDate) — see Migration from direct DCT to drafts for how direct initiation fields map to drafts.

Drafts and signing baskets graduated from beta

• Removed (Beta) suffix from all draft API tags: Signing Baskets, SE Bank Giro, SE Plus Giro, and the new Domestic Credit Transfer draft endpoints
• Signing basket endpoints (GET /payments/drafts, POST /payments/drafts/approve, GET /payments/drafts/approve/{requestId}/status) carry over unchanged from 0.8.0-beta

Account usage field

• usage on the Account object carries over unchanged from 0.8.0-beta

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.

See the Accounts API — Transaction Properties section for integration notes: eventual consistency, title vs payment message, party address, transaction id, OCR, and account balance after transaction.

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