Developers

One API.
Zero folklore.

No tribal knowledge, no "ask your account manager", no surprise behaviours. A payments API that works the way you'd design it — because it was designed by people who've integrated the other ones.

api.veloqen.com/v1
# One call: charge, split, reserve. Idempotent by design.
curl https://api.veloqen.com/v1/payments \
  -u sk_live_…: \
  -H "Idempotency-Key: bk_58291" \
  -d amount=240000 \
  -d currency=EUR \
  -d payment_method=pm_card_tok_81aa \
  -d capture=on_confirmation \
  -d splits[0][account]=acct_supplier_81 \
  -d splits[0][amount]=198000 \
  -d reserve[amount]=6000 \
  -d metadata[booking]=BK-58291

Our DX contract

Boring where it should be. Brilliant where it counts.

Versioned REST

Dated versions, documented changes, long deprecation windows. Your integration from launch day still works years later.

Strong idempotency

Every mutating call takes an idempotency key. Retry storms, double-clicks and network flakes produce exactly one payment.

Signed webhooks

HMAC signatures, replay protection, ordered delivery per object, automatic retries with backoff — and a redelivery button that works.

Deterministic sandbox

Magic amounts trigger exact scenarios: declines by code, 3DS challenges, chargebacks, payout failures. Test the unhappy paths before production finds them.

Hosted components

Drop-in fields that inherit your design system. PCI SAQ-A eligible patterns, accessibility included, no iframe wrestling.

Errors that explain

Machine-readable codes, human-readable causes, and the decline reason the issuer actually sent — not "transaction failed, contact support".

Full API reference, SDKs and integration guides ship with early access.

Integrate it before the kick-off call ends.

Design partners get sandbox keys, direct Slack access to our payment engineers and a say in how the API evolves.