Going live

Audience: 🔌 Integration Client (with 🧑‍💼 company-admin notes where the two meet)

Going live takes a few one-time steps that your API key cannot do. A user or an operator does them.

The path to production

1. A bank connection must exist and be active (User/UI step)

Payments need an active connection to the bank. BankConnector delivers every payment over it and never returns a file for you to upload, so without a connection, submission fails 422.

Setting up and activating a connection is a session-Admin action in the web UI (your API key gets 403 on these routes). Depending on the bank it involves channel-specific steps (SFTP credentials, PGP keys, or the EBICS key-exchange sequence params → generate-keys → send-ini → letter → fetch-hpb), followed by activation. A User at your company does this once per bank.

The setup enforces three things:

• Identifiers the bank makes mandatory. Where a bank's own documentation makes an identifier mandatory (for example Nordea's Signer ID and CAW agreement number), setup cannot be completed until it is saved. Activating the connection answers 422 mandatory_identifier_missing, and error.details.identifiers names each missing value (bankKey, bankName, slot, label).
• SFTP servers that ask for a key and a password. An SFTP connection signs in with the SSH key and the password together when the bank's server requires both.
• A bank that refuses an enrolment step. When the bank answers and refuses (Web Services activation), the call answers 400 bank_rejected, with the bank's own reply in error.details: bankName, headline, bankText and returnCode (the bank's text and code, verbatim; either may be null), and nextSteps.

EBICS setup calls the bank's customer identifier Customer ID; the API field is partnerId, the EBICS protocol's name for it.

On every EBICS connection, each poll also fetches the bank's customer protocol (HAC): its technical log of the EBICS orders it received. A payment whose upload the bank finally refused there becomes rejected. Fetching the protocol consumes it at the bank: if your company also runs its own EBICS software on the same Customer ID, that software does not receive the protocol entries BankConnector has fetched.

At a German bank, each EBICS poll fetches the reports your EBICS agreement includes, as the bank's own record of the agreement (HTD) lists them: the statement, account notifications and intraday reports, and the status report for each kind of payment. BankConnector reads that record when the connection is activated and once a day after, so a report the bank adds to your agreement is picked up the next day. The connection's ebics.reportCoverage lists what is fetched, and noStatusReportFor names any kind of payment no status report in your agreement names. When the bank's record cannot be read, the poll fetches the reports the bank publishes, and reportCoverage.fallback says why.

Set up the connection first (UI), then drive payments from your API-key integration.

2. Approval policy and approvers configured (User/UI step)

Every payment is governed by an approval policy. Until your company locks its own, the built-in default applies: two distinct approvers on every payment, and the user who created a payment may be one of them. Approvers are named in the approval policy that governs each bank, and each approver needs 2FA enrolled (and, in some flows, an identity enrollment). Approvals happen in the UI or through approver session calls, not with your API key.

Before go-live, decide the two separate controls your policy sets:

• Approval required (four eyes): whether a payment needs approving before it goes to the bank, and by how many distinct approvers (e.g. the default two on every payment, or approval only above an amount threshold). A payment takes exactly the number of approvers its policy requires: a policy that requires one approver releases a payment on that one signature.
• Maker-checker: whether the user who created a payment (the maker) is excluded from approving it. Off in the default; opt in per policy or company-wide.

3. Connection environment vs deployment posture, and the real-payment boundary

Each connection carries environment: test | production, independent of the deployment's posture. Two rules apply:

• A production deployment refuses to activate or deliver a production connection that points at a bank's test host (stest.…, …sandbox…, customertest, or a hostname/SFTP-login labelled test). Point production connections at production bank hosts.
• ⚠️ On the deployed sandbox, real payments can never move. A server-wide hard stop refuses every production-environment delivery for every company, so sandbox.bankconnector.com is safe to experiment on.
• Whether a company can reach a real bank is decided by the deployment, not by a per-company setting. On production, real payments move over an active production connection.

4. Bank IP allow-listing / static egress

Some bank environments only accept connections from registered IP addresses (Danske Bank's customer-test environment is one). If your bank asks for the address BankConnector connects from, ask support for it before your first live send, and give your bank notice before any change to it.

5. Production credentials

Your production API key is separate from your sandbox key. Keys don't expire, so write a rotation runbook now: create a new key, cut over, revoke the old one. An admin of the company the key belongs to does this. Store the key in a secrets manager, never in source.

Production behaviour differences to expect

Rate limiting is already on at sandbox.bankconnector.com with the same defaults as production, so test your backoff there. → Rate limiting

The guides and the OpenAPI spec are at docs.bankconnector.com. Don't fetch the spec from an API host at runtime: on a production API instance, GET /openapi.json and GET /openapi.yaml return 404. GET /docs 302-redirects to the docs site.

Final go-live checklist

• Bank connection created and active (host-to-host), verified in the UI
• Approval policy decided (approval required, and maker-checker); its approvers enrolled with 2FA
• Production connection points at production bank hosts
• If the bank restricts connecting IP addresses: BankConnector's address registered with it
• Production API key issued, stored in a secrets manager, rotation runbook written
• OpenAPI spec vendored at build time (not fetched from a live production instance)
• The Best practices pre-launch checklist is green
• End-to-end dry run in sandbox reproduces your real payment shapes