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. (This is a known rough edge in the platform's sandbox model, not something this guide can paper over — it's tracked as an open design item.)

4. Bank IP allow-listing / static egress

Banks typically allow-list the IPs that may connect to them. The BankConnector deployment must therefore present a static egress IP (via NAT / Elastic IP). For most customers on the hosted bankconnector.com platform, this is handled by the operator — 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. If your company runs an on-premises deployment instead, this is your own responsibility.

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.

Operational readiness (🏗️ / shared)

A few deployment facts worth confirming with your operator, since they affect you:

• Migrations run as a separate pre-deploy step. /ready returns 503 until the schema is migrated — a rollout isn't serving until that's done.
• Health/readiness: /health is liveness (always 200, with warnings when degraded); /ready gates traffic. Point your uptime checks at the right one.
• A degraded /health warning like egress-ips-unset means the static egress isn't configured — worth catching before you send to a bank that allow-lists.

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