enable-banking-faq-best-practices

Original：🇺🇸 English

Translated

Answer Enable Banking API FAQs and apply best practices for ASPSP/PSU terminology, pricing and activation expectations, production compliance fields, restricted application account linking, ASPSP identifiers and BICs, beta integrations, user identification, balances, transaction history and continuation keys, PSU headers, rate limits, JWT handling, session validity, expired sessions, language selection, ASPSP_ERROR retries, iframe/WebView/CORS issues, payment statuses, bulk payments, TPP infrastructure, and sandbox credential lookup. Use when Codex needs to explain edge cases, design robust Enable Banking behavior, or troubleshoot recurring API and UX problems.

2installs

Sourceberget1411/enable-banking-skills

Added on2026-04-25

NPX Install

npx skill4agent add berget1411/enable-banking-skills enable-banking-faq-best-practices

SKILL.md Content

View Translation Comparison →

Enable Banking FAQ Best Practices

Overview

Use this skill for FAQ-driven implementation guidance and recurring Enable Banking edge cases. For endpoint shapes use

enable-banking-api

; for Control Panel setup use

enable-banking-control-panel

; for sandbox behavior use

enable-banking-sandbox

; for widgets use

enable-banking-ui-widgets

.

Workflow

Identify the topic: onboarding/compliance, ASPSP identity, account/balance data, transactions, PSU headers/rate limits, auth/session, language/UX, payments, TPP infrastructure, or sandbox.
Read references/faq-best-practices.md for the relevant topic.
Translate the FAQ into concrete product behavior, error handling, data modeling, or user messaging.
Preserve Enable Banking error bodies and operational identifiers so issues can be correlated with Control Panel request logs.

Core Rules

Do not share Enable Banking JWTs or private keys with end users. JWTs identify the application and can access all sessions/payments belonging to that app.
Base business logic on API
```
error
```
codes, not only HTTP status codes.
Treat ASPSP name + country as the ASPSP identity; dynamically refresh ASPSPs before reconnect flows.
Use
```
entry_reference
```
for transaction matching when available; do not use
```
transaction_id
```
as a stable transaction identifier.
Handle continuation keys until absent, even if a page contains an empty transaction list.
For online user-triggered data fetches, provide all required PSU headers; for background fetches, provide none.
Handle
```
EXPIRED_SESSION
```
even when
```
valid_until
```
is in the future by prompting reauthorization.
Do not run Enable Banking authorization in iframes. Avoid mobile WebViews unless they are explicitly configured for external redirects/deep links; prefer the system browser.
Treat
```
XXX
```
account currency, multiple balances, missing fields, beta ASPSPs, and variable transaction history as normal integration realities.

Project Placement

When applying this in an application:

Put robust API semantics and retry/session logic in backend services.
Put persisted session/account/transaction/payment state behind a database/data-access boundary.
Keep UI messaging in frontend code, but avoid leaking low-level banking internals unless useful for user recovery.
Use Control Panel request IDs and Enable Banking IDs in logs for support correlation, while redacting credentials, JWTs, private keys, authorization codes, and PSU headers.