For developers
Server-to-server API, built for platforms
Create invoices, watch settlement webhooks and reconcile payouts programmatically.
POST /v1/invoices
Authorization: Bearer sk_live_...
{
"amount": "12500.00",
"currency": "USD",
"accept": ["USDC", "USDT"],
"settle_to": "SGD",
"customer_email": "[email protected]"
}What is the first API call I make?
Create a payment server-to-server and get back a hosted payment link to share. From there you watch signed settlement webhooks and reconcile payouts programmatically. Idempotency keys are mandatory on every call, so a retry cannot double-charge.
Can I build against a sandbox before going live?
Yes. The sandbox runs on a test network and issues real invoices with working payment links using test tokens, so a webhook handler can be exercised end to end before a single live payment moves.
How are API requests authenticated?
An API key and secret, with an HMAC-SHA256 signature over the request. Webhooks are signed too and carry their signature in a header, so a handler verifies the payload rather than trusting its source address.
The integration surface
- Primary endpoint
- POST /sdk/server/create-payment → hosted paymentUrl
- Authentication
- API key + secret, HMAC-SHA256 signature, mandatory idempotency key.
- Webhooks
- Signed via x-kollect-signature; kollect-server interface only.
- Sandbox
- Sepolia (sandbox only)
Creating a payment
One server-to-server call creates a payment and returns a hosted payment link: POST /sdk/server/create-payment → hosted paymentUrl. Your system never renders a payment form and never touches a wallet connection, because the hosted link owns that surface. What you hold is the reference the payment was created against.
Requests carry an API key and secret with an HMAC-SHA256 signature, and an idempotency key is mandatory on every call. That last part is not a convenience. Payment creation is exactly the operation a network timeout makes ambiguous, and without an idempotency key a client retry is indistinguishable from a second invoice.
Rate limiting is 1000 req/60s per API key (default), which is a ceiling on bursts rather than on volume: a batch job creating invoices should pace itself rather than assume the limit will not be reached.
Receiving settlement events
Settlement is asynchronous, so the API tells you a payment exists and webhooks tell you what happened to it. Signed via x-kollect-signature; kollect-server interface only. A handler verifies that signature over the raw request body before parsing anything, because a webhook endpoint is a public URL and a signature is the only thing separating a real notification from a forged one.
Treat delivery as at-least-once. Key your handler on the event identifier and make it safe to run twice, because a duplicate is normal operation rather than an error condition. Webhook verification has its own page, since it is the part most easily got subtly wrong.
Which rail a payment takes
Three rails are supported: S2S, S2F, F2S. Fiat-to-fiat is unsupported by design. That matters at integration time because the rails differ in what they need from you. A stablecoin-to-stablecoin payment needs a wallet address you control. A stablecoin-to-fiat payment needs a bank account nominated at onboarding, and a licensed partner handles the conversion.
Live payments run on Ethereum mainnet and Polygon, and the sandbox runs on Sepolia (sandbox only) so a handler can be exercised end to end before anything of value moves. The sandbox issues real invoices with working payment links, which is what makes it a genuine test rather than a mock.
Developer questions
Every answer here is mirrored verbatim in this page's FAQ structured data, so nothing is hidden behind a click.
Full endpoint reference lives in the developer docs.
Can I use Kollect through my own product?
Yes. There is a server-to-server API for creating invoices and receiving settlement webhooks, and a white-label option for partners who want Kollect under their own brand.
What does Kollect give developers to build against?
Signed requests, mandatory idempotency keys on every call, and signed webhooks, with a sandbox environment to build and test against before you take a single live payment.