⌘K
sandbox.bankconnector.com API Reference

Send your first payment in 5 minutes

BankConnector is an ISO 20022 payment engine as a service: send canonical payment JSON in, and it validates, converts to the exact pain.001 flavour your bank expects, delivers it, then normalises whatever comes back (camt.053, pain.002) into one shape. You write one integration; BankConnector handles the bank-specific XML dialects.

Follow the three steps below, or open the interactive playground, which provisions a private sandbox in one click and animates a payment round-trip. Looking for a specific endpoint? Go to the API Reference.

Quickstart

Everything here runs against the public sandbox at https://sandbox.bankconnector.com. It needs no signup or card, and every bank is a simulated Demo Bank, so no real payments can move.

1. Get a sandbox key

POST /api/sandbox/provision needs no auth. It returns an isolated sandbox: a company, an admin login, and an API key wired to an active demo bank connection:

curl -X POST https://sandbox.bankconnector.com/api/sandbox/provision
# 201
# {
#   "apiKey":    "key_…",           # your data-plane credential (X-API-Key)
#   "companyId": "comp_…",          # which company to act as
#   "baseUrl":   "https://sandbox.bankconnector.com",
#   "bank":      { "key": "danske-dk", "name": "Danske Bank", "country": "DK" },
#   "dashboardLogin": { "url": "…", "email": "…", "setPasswordUrl": "…" },
#   "firstPayment":   { … a copy-paste-ready first request … }
# }

The apiKey and companyId are all you need to send payments. Data-plane calls name the key's own companyId; any other company is refused with 403. The dashboardLogin creds let you sign in to the web UI to watch payments move. Open setPasswordUrl to choose a password (single-use, expires after 7 days), then log in with email and that password; the admin session is only needed to manage companies & users.

2. Send a payment

POST /api/journal/payments with X-API-Key and a canonical payment. Pass companyId in the body. The debtor account is your sandbox's own IBAN, from firstPayment.body: every sandbox gets its own, and the demo bank's camt.053 for an account reaches only the company that holds it:

curl -X POST https://sandbox.bankconnector.com/api/journal/payments \
  -H "X-API-Key: $BC_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-10432-v1" \
  -d '{
    "companyId":   "comp_…",
    "bankKey":     "danske-dk",
    "environment": "test",
    "payment": {
      "messageId": "ORDER-2026-10432",
      "initiatingParty": { "name": "Acme Holding" },
      "payments": [{
        "paymentId": "p1",
        "paymentType": "sepa",
        "executionDate": "2026-07-15",
        "debtor": {
          "name": "Acme Holding",
          "account": { "iban": "DK…" },
          "agent": { "bic": "DABADKKK" }
        },
        "transactions": [{
          "endToEndId": "e1",
          "amount": "5.00",
          "currency": "EUR",
          "creditor": {
            "name": "Acme GmbH",
            "account": { "iban": "DE89370400440532013000" },
            "agent": { "bic": "COBADEFFXXX" }
          }
        }]
      }]
    }
  }'
# 201 { "id": "...", "journalNo": "...", "status": "queued-for-delivery", "xml": "<Document>...", "deliveryMode": "host-to-host" }

A 201 means the payment was accepted and converted to the bank's format. The status field tells you what happened next: the sandbox auto-releases, so here it's queued-for-delivery. (With an approval policy it would be pending-approval instead, see Submitting payments.) Delivery to the demo bank is asynchronous.

3. Read the result

The demo bank replies within a few seconds with a real-format pain.002 and camt.053. Read the reconciled state with X-API-Key and companyId:

curl -H "X-API-Key: $BC_KEY" \
  "https://sandbox.bankconnector.com/api/journal/reconciliation?companyId=comp_…"
# status "executed", state "cleared"

GET /api/journal/list?companyId=comp_… gives the same view as a paged list. That's the full loop: provision, send, read.

Where to next