Neobank integrations

galanthus exposes neobank API integrations through dynamically loaded provider plugins. The current public surface ships Revolut and Wise. FinTS and EBICS remain the canonical bank-protocol command paths; neobank providers expose their own auth/setup and provider operations, and library callers gate shared operations with gln_check_backend_operation_support.

Provider API references:

• Revolut Business API documentation
• Wise Platform API documentation

Plugin model

Neobank backends are delivered as shared libraries that implement the current plugin ABI. Each plugin owns the wire-level concerns of one provider: HTTP base URL, auth scheme, idempotency conventions, payload shape, and provider-specific error details.

Plugin loading goes through an explicit trust boundary. Discovery resolves a plugin id such as revolut or wise to a concrete binary on the configured search path. Before a backend is loaded, the library checks whether the resolved binary is already trusted; if it is not, the operator approves it through plugin approve and the approval is recorded as a pin against that binary. Plugin trust failures surface as GLN_ERR_PLUGIN_NOT_TRUSTED; discovery failures surface as GLN_ERR_PLUGIN_NOT_FOUND.

Revolut

Revolut is integrated against the Revolut Business API. It uses an OAuth flow with a client-assertion private key, supports recipient management, and stages outgoing payments as Revolut payment drafts.

CLI entry points:

• profile init with --backend revolut records the Revolut endpoint, client id, private-key path, redirect URI, and shared profile metadata.
• profile auth login revolut completes the OAuth browser or non-interactive authorization-code exchange.
• profile auth status revolut reports the redacted token status for the active Revolut profile.
• gln revolut payment-drafts create | list | show | delete manages Revolut payment drafts. See create, list, show, and delete.
• gln revolut recipients create | list | delete manages Revolut counterparties. See create, list, and delete.

Library entry: open a Revolut backend with gln_open_revolut_backend. The config carries the OAuth client id, redirect URI, client-assertion key id, environment, optional profile name, optional plugin path, dump directory, and timeout. The PEM client-assertion key is supplied as gln_secret_t*. Revolut backends require a state store and a Revolut token store. The full library reference lives at Revolut.

Wise

Wise is integrated against the Wise API. It uses a Wise PersonalToken stored in encrypted host storage or in the supplied Wise token store, depending on the opened backend configuration.

CLI entry points:

• profile init with --backend wise records the Wise endpoint, user, product metadata, and backend binding.
• profile auth login wise stores the Wise PersonalToken from a hidden prompt or --token-stdin.
• profile auth status wise reports the redacted token status for the active Wise profile.

Library entry: open a Wise backend with gln_open_wise_backend. The config carries the Wise endpoint, optional Wise profile id, optional local profile name, optional plugin path, dump directory, and timeout. Wise backends require a state store and a Wise token store. The full library reference lives at Wise.

Provider surface

The table below records the provider-specific surface documented by the current public CLI and C ABI.

Shared backend operations must be capability-probed at runtime before a caller exposes them for a Revolut or Wise backend. Direct SEPA transfers, SEPA direct debits, standing orders, holdings, prepaid top-up, TAN, and resume workflows remain FinTS / EBICS surfaces in the current public CLI reference.

See also

• Revolut library reference
• Wise library reference
• Conventions
• Backend handles
• Secrets
• CLI reference index