Error handling

Every failed call — validation, HTTP, or network — raises the same typed class: LinaPayError.

class LinaPayError extends Error {
constructor(
  message: string,
  public statusCode?: number,
  public originalError?: unknown,
)
name: 'LinaPayError'
}

Catching errors

import { LinaPayError, createConsent } from '@lina-openx/web-lina-pay-sdk'

try {
const consent = await createConsent(credentials, payload)
} catch (error) {
if (error instanceof LinaPayError) {
  if (!error.statusCode) {
    // Client-side validation failure — no network call was made
    console.error('Invalid payload:', error.message)
    return
  }

  switch (error.statusCode) {
    case 400:
      console.error('Invalid payload:', error.message)
      break
    case 401:
    case 403:
      console.error('Invalid credentials')
      break
    case 500:
      console.error('Server error')
      break
    default:
      console.error(error.statusCode, error.message)
  }
} else {
  throw error // not from the SDK
}
}

Validation vs. HTTP errors

Some calls validate their payload before any network request and raise LinaPayError('Invalid payload') (no statusCode) immediately — createPaymentRequest, createAutomaticPaymentRequest, cancelPaymentRequest, cancelPayment, getBankIdentifiers, and the receiving-account functions all do this. Everything else surfaces the HTTP status returned by the API, or a network failure with no statusCode at all.

`statusCode`	Meaning
(none)	Client-side validation failed, or a network/timeout error occurred.
`400`	Invalid payload rejected by the API.
`401` / `403`	Invalid or insufficient credentials.
`404`	Resource not found.
`500`+	Unexpected server error.

Next steps

Web SDK overview — the full method map.
Payments — the flow these errors most commonly surface in.