Going live

Going live takes a few one-time steps that your API key cannot do. An Admin of the company does them in the web app.

What the sandbox does not show you

The deployed sandbox simulates the bank side, so the first contact with a real bank happens on production.

A sandbox run proves that your integration builds valid requests and handles the results. It does not prove how a bank accepts your payment shapes or how your approval policy holds them.

Rate limiting is on at sandbox.bankconnector.com, 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 production, GET /openapi.json and GET /openapi.yaml return 404, and GET /docs redirects to the docs site.

The path to production

1. A bank connection must exist and be active

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 one, submission fails 422.

An Admin of the company sets up and activates a connection in the web app; your API key gets 403 admin_required on these routes. Depending on the bank this involves SFTP credentials, PGP keys or an EBICS key exchange, then activation. This happens once per bank.

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), activation 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. The connection signs in with both when the bank's server requires it.
• 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 reply in error.details: bankName, headline, bankText and returnCode (the bank's text and code, verbatim; either may be null), and nextSteps.

On every EBICS connection each poll also fetches the bank's customer protocol (HAC), and 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 connection, that software no longer receives the entries BankConnector has fetched.

2. Approval policy and approvers configured

Every payment on production is governed by an approval policy. Until your company has its own policy in status active (not draft), 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 policy that governs each bank. Approvals happen in the web app or through approver session calls, not with your API key.

An approver enrols a second factor only if your company requires 2FA, or when approving from an ERP add-on.

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 (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 and the real-payment boundary

Each connection carries environment: test | production.

• On the sandbox, real payments can never move: every production delivery is refused for every company.
• On production, real payments move over an active production connection. Production refuses to activate or deliver a production connection that points at a bank's test server: 422 production_endpoint_is_test_host. Point it at the bank's production host.
• A test connection on production exists for one case: an SFTP test record on the bank's own test server. Its payments move no money and are released without approval. For Danske Bank Web Services, Nordea Corporate Access, OP and Bank Connect a test connection is refused with 422 production_only_channel: those banks are reached in production only.

4. Bank IP allow-listing

Some banks only accept connections from registered IP addresses. Recorded evidence, from earlier onboarding cases and our own probes (not a statement from the banks): DNB, Deutsche Bank and HSBC check the address, and Danske Bank checks it on its customer-test environment only. Don't assume the same of other banks.

For such a bank, GET /api/banks/{bankKey}/setup-info returns the addresses in sourceIps. Register them with the bank before your first live send, and give the bank notice before any change to them. Support can help if your bank asks for something else.

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. See Authentication. Store the key in a secrets manager, never in source.

Final go-live checklist

• Bank connection created and active, verified in the web app
• Approval policy decided (approval required, and maker-checker) and active, with its approvers named
• Production connection points at the bank's production host
• If the bank restricts connecting IP addresses: the sourceIps 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
• First production payments watched through approval and delivery, since the sandbox delivers to the Demo Bank and skips approval while your company has no active approval policy