Payments API

The Payments API allows Third Party Providers (TPPs) to initiate payments on behalf of authorized users. All payment endpoints require the PSP_PI (Payment Initiation) scope.

Payment Authorization Flow

All payment initiations follow a redirect-based authorization flow. When you initiate a payment, the user must authorize it through the Lunar app before it can be executed.

Payment Types

Domestic Credit Transfer

Standard bank transfers within Denmark, Sweden, or Norway.

Initiate Transfer


POST /payments/domestic-credit-transfer

Field	Required	Description
`redirectUrl`	Yes	URL to redirect user after authorization
`accountId`	Yes	Source account ID
`recipientBBAN`	Yes	Recipient’s BBAN (11-14 characters)
`recipientName`	DK only	Required for instant transfers in Denmark
`amount`	Yes	Payment amount
`currency`	Yes	Currency code (ISO 4217)
`message`	No	Message to recipient (see limits below)
`title`	No	Transaction title for sender (max 140 chars)
`date`	No	Execution date (ISO-8601, defaults to earliest possible)

Message length limits by country: - Denmark (instant): 140 characters

Denmark (intraday): 20 characters - Sweden: 12 characters - Norway: 70 characters All Lunar transfers in Denmark are executed as instant transfers.

Get Transfer Status


GET /payments/domestic-credit-transfer/{id}

Returns the payment details including current status.

Danish Payment Slip (GIRO/FI)

Traditional Danish payment slips for utility bills and invoices.

Initiate Payment Slip


POST /payments/dk-payment-slip

Field	Required	Description
`redirectUrl`	Yes	URL to redirect user after authorization
`accountId`	Yes	Source account ID
`amount`	Yes	Payment amount
`currency`	Yes	Currency code (ISO 4217)
`type`	Yes	GIRO/FI type: `01`, `04`, `15`, `71`, `73`, or `75`
`debtorId`	Yes	Your identifier (payer reference)
`creditorId`	Yes	Creditor number (max 8 characters)
`message`	No	Payment message (max 140 characters)
`title`	No	Transaction title for sender
`date`	No	Execution date (ISO-8601)

Get Payment Slip Status


GET /payments/dk-payment-slip/{id}

Standing Orders

Recurring scheduled payments for regular bills or transfers.

List Standing Orders


GET /payments/standing-order

Returns all standing orders for the authenticated user.

Create Standing Order


POST /payments/standing-order

Field	Required	Description
`senderAccountId`	Yes	Source account ID
`senderMessage`	Yes	Message/reference for sender
`receiverAccount`	Yes	Recipient’s BBAN
`receiverMessage`	Yes	Message to recipient
`amount`	Yes	Payment amount
`currency`	Yes	Currency code
`activeFrom`	Yes	Start date (ISO-8601 date)
`frequency`	Yes	Payment schedule (see below)
`terminationPolicy`	Yes	When to stop payments
`redirectUrl`	No	Redirect URL after authorization

Frequency Options

Standing orders support flexible scheduling:

Daily:


{ "daily": true }

Weekly:


{ "weekly": { "dayOfWeek": "MONDAY" } }

Monthly:


{ "monthly": { "interval": 1, "paymentDay": "15" } }

Payment day options: FIRST_BANK_DAY, LAST_BANK_DAY, or a specific day (1-31).

Get Standing Order


GET /payments/standing-order/{id}

Delete Standing Order


DELETE /payments/standing-order/{id}

Payment Statuses

All payment types return a status object with the following states:

State	Description
`AWAITING_APPROVAL`	Payment created, waiting for user authorization
`PENDING`	Payment authorized, pending execution
`COMPLETED`	Payment successfully executed
`FAILED`	Payment execution failed (see `failureCode`)
`CANCELLED`	Payment was cancelled
`UNKNOWN`	Status could not be determined

Always check the payment status after the user returns from the authorization flow. A redirect back to your redirectUrl does not guarantee the payment was approved.

Error Handling

Status	Description
`400`	Invalid request (e.g., invalid BBAN, insufficient data)
`404`	Payment not found
`500`	Internal server error

Error responses include an errorCode and message with details about the failure.