Developers

One canonical JSON.
A safe sandbox. Ship the same afternoon.

OpenAPI 3.1. X-API-Key auth. Required idempotency keys. Signed webhooks. The hard parts (bank dialects, channels, certificates) live on our side of the line.

Initiate a payment

One request. One canonical shape.

Send the same JSON regardless of which bank handles it. We pick the right ISO 20022 profile, the right channel, and the right signing key.

POST /v1/payments
X-API-Key: bc_live_…
Idempotency-Key: 7f3c…

{
  "tenant_bank_id": "tb_01H…",
  "debtor_iban": "DK5000400440116243",
  "creditor": {
    "name": "Acme Supplies ApS",
    "iban": "DK9520000123456789"
  },
  "amount_minor": 125000,
  "currency": "DKK",
  "remittance": "Invoice 2026-0418",
  "requested_execution_date": "2026-06-17"
}

What's in the box

Sensible defaults. Honest constraints.

OpenAPI 3.1

Generate clients in your language. Schemas are the source of truth.

Idempotency keys

Required on writes. Replays return the original result, not a duplicate payment.

Signed webhooks

HMAC-signed deliveries with timestamp tolerance. Verify before processing.

Sandbox tenant

Run the full flow against a fake bank profile. No production credentials needed.

BigInt money

Amounts in minor units. No floats. No silent rounding.

Explicit errors

Validation failures point at the field and the bank rule that rejected it.

Live API reference

Coming soon.

The interactive OpenAPI reference is being prepared for public release. In the meantime, partners get the full spec, a sandbox tenant, and example payloads on request.

Request sandbox access →

Want to build against it?

Become a partner