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 human and operator actions. Plan for them.

The path to production

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

Payments to a host-to-host bank require an active host-to-host connection. There is no automatic fall-back to file-return — without the 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 human 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 (human/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.
• ⚠️ The deployment posture (sandbox vs production) is not, by itself, what stops real money from moving. The actual hard boundary is per company: a company flagged sandboxOnly can never deliver a production-environment payment, on any posture. A company that is not sandboxOnly can create and activate a real production connection and send real money — including on a server running in sandbox posture. Don't assume "I'm pointed at a sandbox deployment" is enough; confirm your company's sandboxOnly status with your operator before you rely on "no real money can move" as a property of the environment alone.

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

Because the docs surface is 404 in production, don't have your client fetch the spec at runtime from a production instance. This documentation site vendors the spec at build time instead, so it stays available regardless.

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