Accounts API

The Accounts API allows Third Party Providers (TPPs) to access account information on behalf of authorized users. This API requires the PSP_AI (Account Information) scope.

Capabilities

List Accounts

Retrieve a list of all accounts accessible to the authenticated user.

GET /accounts

Each account includes:

List Transactions

Retrieve transaction history for a specific account.

GET /accounts/{accountId}/transactions

Query Parameters

Response Structure

The response is a TransactionsResponse wrapper object:

Transaction Properties

Each transaction includes:

Billing amount vs. transaction amount

A transaction carries two amount fields:

• transactionAmount — the amount in the original currency of the payment (e.g., EUR 20 for a purchase at a European shop). Can be null in some special cases for example when the payment was never reserved on the account, such as certain direct settlements.
• billingAmount — the amount that was actually posted to the account, in the currency of the posting. For foreign-currency transactions this is the converted amount after exchange.

When both currencies are the same, the two values will match. When they differ, the currencyExchange object provides the conversion details.

Example: A card payment made for 20 EUR:

{
  "billingAmount": { "amount": -149.0, "currency": "DKK" },
  "transactionAmount": { "amount": -20.0, "currency": "EUR" },
  "currencyExchange": {
    "currency": "EUR",
    "targetCurrency": "DKK",
    "exchangeRate": 7.45
  }
}

Mapping properties for transaction fields

Here is a mapping of our statuses, to codes of the ISO 20022 data table:

Mapping to NextGenPSD2 (Berlin Group) fields:

Lunar uses transactionTime and postingTime as full ISO-8601 timestamps. The NextGenPSD2 spec uses bookingDate, valueDate, and transactionDate as date-only (ISODate) fields. The mapping between them depends on the transaction status:

bookingDate — “The date when an entry is posted to an account on the ASPSP’s books.”

• Maps to postingTime. Both represent when the transaction was recorded on the account.
• null for pending transactions, just as bookingDate is absent for pending entries in NextGen.

valueDate — “The date at which assets become available to the account owner in case of a credit, or cease to be available in case of a debit. If entry status is pending, refers to an expected/requested value date.”

• For settled transactions (financial status): maps to postingTime. Lunar does not distinguish between the booking date and the value date — settlement, booking, and funds availability happen at the same time.
• For future/scheduled transactions (future status): maps to transactionTime, which holds the scheduled execution date — equivalent to the “expected/requested value date” in NextGen.
• For other pending transactions (authorization, interim, initiated): Lunar does not expose an expected value date. There is no direct equivalent.

transactionDate (NextGen card transactions only) — “Date of the actual card transaction.”

• Maps to transactionTime. Both represent when the transaction was initiated (e.g., the moment a card was swiped or a transfer was created).

  Reconciliation guidance:

• Use postingTime for matching against bank statements and cash-flow reconciliation — this is when the account balance actually changed. It corresponds to bookingDate in NextGenPSD2.

• Use transactionTime to determine when the transaction was initiated, e.g., for dispute timelines or user-facing activity logs.

• For pending transactions (authorization, interim, initiated), only transactionTime is available. postingTime is populated once the transaction reaches financial status.

• For future/scheduled transactions, transactionTime represents the expected execution date and can be used as an anticipated settlement date.

Get Transaction by ID

Retrieve a single transaction by its identifier.

GET /accounts/{accountId}/transactions/{transactionId}

Path Parameters

Headers

Returns a single Transaction object (same structure as in the list endpoint).

Funds Confirmation

Check whether a specific amount is available in an account. This is useful before initiating a payment to ensure it won’t fail due to insufficient funds.

GET /funds-confirmation

Request Body

{
  "accountId": "account-uuid",
  "amount": 100.0,
  "currency": "DKK"
}

Response

{
  "fundsAvailable": true
}

Required Scopes

Error Handling

Each endpoint defines its own set of error responses:

Error responses include an errorCode and message for debugging.