Going Live

Audience: 🔌 Integration Client (with 🏗️ operator notes where the two meet)

Moving from sandbox to real payments involves a few steps that are not driven by your API key; they're one-time User and operator actions. Plan for them.

The path to production

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

Payments require an active connection to the bank. BankConnector delivers every payment for you over that connection. It 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, by design). 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.

Sequence your onboarding accordingly: connection first (UI), then your API-key integration drives payments.

2. Approvers configured, if you use maker-checker (User/UI step)

If an approval policy applies, approvers must be set on the connection, and each approver needs 2FA enrolled (and, in some flows, an identity enrollment). Approvals happen in the UI or via approver session calls; again, not your API key. Decide your policy (e.g. the default dual-approval) before go-live.

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

Each connection carries environment: test | production, independent of the deployment's posture. Two guard-rails to know:

• 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), and vice-versa. Point production connections at production bank hosts.
• ⚠️ On the deployed sandbox, real money 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 by construction. (The hard stop is specific to the deployed sandbox; a local dev server is exempt so developers can still exercise real delivery flows.)
• A second, per-company guarantee also holds on any posture: a company flagged sandboxOnly can never deliver a production payment. So on production, real money moves only for a non-sandboxOnly company over an active production connection. Both must be true.

4. Bank IP allow-listing / static egress

Banks typically allow-list the IPs that may connect to them, so BankConnector connects from a static egress IP. On the hosted bankconnector.com platform this is handled for you: confirm your egress IP with support before your first live send, and notify your bank at least 5 business days before any egress IP change.

5. Production credentials

Your production API key is separate from your sandbox key. Because keys don't expire, establish a rotation runbook now: create-new → cut-over → revoke-old, performed by a workspace admin. Store the key in a secrets manager, never in source.

Production behaviour differences to expect

Rate limiting is not a production-only surprise. It's enabled on any deployed server that isn't an explicit local dev/test box, so it is already on at sandbox.bankconnector.com with the same defaults. If your client hits 429 in production it would have hit it in sandbox too; test your backoff there. → Rate limiting

Docs live only at docs.bankconnector.com. The guides and the OpenAPI spec are served from there (the spec is vendored at build time). 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 by design. (GET /docs is not 404'd in any posture: it 302-redirects to the hosted docs site. The old in-app interactive reference is gone.) Treat docs.bankconnector.com as the single source in every environment.

Final go-live checklist

• Bank connection created and active (host-to-host), verified in the UI
• Approval policy decided; approvers enrolled with 2FA (if using maker-checker)
• Production connection points at production bank hosts
• Static egress IP in place and the bank has allow-listed 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