Event types

Qint currently emits two event types. Build your handler to ignore event types it doesn’t recognize (still returning 2xx) so future event types never break you.

`payment.status`

Sent to every active endpoint on each status transition of a payment intent — and re-sent for the intent’s current status when the underpaid flag changes or the payment is reversed (see below). Every event carries the full set of fields; the ones that don’t apply are false or null.

{
  "type": "payment.status",
  "intentId": "pi_x7k2m9p4q1w8",
  "status": "settled",
  "amount": 49.90,
  "currency": "CHF",
  "assetSymbol": "USDT",
  "underpaid": false,
  "receivedAmount": null,
  "underpaidBps": null,
  "expectedCryptoAmount": "55.48765432",
  "receivedCryptoAmount": "55.48765432",
  "invoiceId": null,
  "paymentLinkId": null,
  "reversed": false,
  "reversedAt": null,
  "creditAmount": 49.65,
  "creditCurrency": "CHF",
  "creditRate": 1,
  "occurredAt": "2026-07-08T09:24:03+00:00"
}

Field	Type	Description
`type`	string	Always `payment.status`.
`intentId`	string	The payment intent (`pi_…`) this event is about.
`status`	string	The intent’s status after the transition: `initiated`, `pending`, `confirmed`, `settled`, `failed`, `expired` or `cancelled`.
`amount`	number	The fiat amount of the payment.
`currency`	string	`CHF`, `EUR`, `USD` or `GBP`.
`assetSymbol`	string \| null	The crypto asset the buyer chose, once chosen.
`underpaid`	boolean	See underpayment fields.
`receivedAmount`	number \| null	See underpayment fields.
`underpaidBps`	integer \| null	See underpayment fields.
`expectedCryptoAmount`	string \| null	The quoted crypto amount, as an 8-decimal string. `null` until the buyer has picked an asset.
`receivedCryptoAmount`	string \| null	What actually arrived, as an 8-decimal string. `null` until the payment partner has reported a deposit.
`invoiceId`	string \| null	Set when the payment pays an invoice (`inv_…`).
`paymentLinkId`	string \| null	Set when the payment came through a payment link (`pl_…`).
`reversed`	boolean	See reversal fields.
`reversedAt`	string \| null	See reversal fields.
`creditAmount`	number \| null	See credit fields.
`creditCurrency`	string \| null	See credit fields.
`creditRate`	number \| null	See credit fields.
`occurredAt`	string (ISO 8601)	When the transition happened.

Credit fields

The settled event says what the payment added to your balance. The three fields were added on 20 October 2026; they are null on every other status and on payments settled before that date.

Field	Type	Description
`creditAmount`	number \| null	The amount credited to your balance, 2 decimal places, in `creditCurrency`.
`creditCurrency`	string \| null	Your Account Currency at the time of the quote: `CHF`, `EUR`, `USD` or `GBP`.
`creditRate`	number \| null	Units of `creditCurrency` per 1 unit of `currency`, fixed when the buyer was quoted. `1` when the two currencies match.

The event does not carry feeAmount, netAmount or settledAmount. Read them from GET /api/v1/intents/{id} after a settled event.

Fulfil on status: "settled" and nothing else. confirmed means the crypto is confirmed on-chain but settlement to fiat hasn’t completed.

Underpayment fields

When the payment partner detects that a buyer sent less than the quoted amount, the payment.status event is re-emitted for the intent’s current (unchanged) status, carrying the underpayment fields:

{
  "type": "payment.status",
  "intentId": "pi_x7k2m9p4q1w8",
  "status": "pending",
  "amount": 49.90,
  "currency": "CHF",
  "assetSymbol": "USDT",
  "underpaid": true,
  "receivedAmount": null,
  "underpaidBps": null,
  "expectedCryptoAmount": "55.48765432",
  "receivedCryptoAmount": "53.20000000",
  "invoiceId": null,
  "paymentLinkId": null,
  "reversed": false,
  "reversedAt": null,
  "occurredAt": "2026-07-08T09:21:40+00:00"
}

A payment short by no more than the merchant’s accepted underpayment settles with underpaid: true — as does an underpaid payment accepted from the review queue — and the settled event says how much was actually received:

{
  "type": "payment.status",
  "intentId": "pi_x7k2m9p4q1w8",
  "status": "settled",
  "amount": 100.00,
  "currency": "CHF",
  "assetSymbol": "USDT",
  "invoiceId": null,
  "paymentLinkId": null,
  "underpaid": true,
  "receivedAmount": 99.70,
  "underpaidBps": 30,
  "expectedCryptoAmount": "111.20000000",
  "receivedCryptoAmount": "110.86640000",
  "occurredAt": "2026-07-08T09:24:03+00:00"
}

Field	Type	Description
`underpaid`	boolean	`true` when the received amount is short. A flag, not a status — the intent’s status is unchanged by the detection itself.
`receivedAmount`	number \| null	The fiat amount actually received (in `currency`) — the amount the merchant is credited for, before Qint’s fee. `null` unless the payment is underpaid.
`underpaidBps`	integer \| null	The shortfall in basis points of `amount` (`30` = 0.3 %). `null` unless the payment is underpaid.
`expectedCryptoAmount`	string \| null	The quoted crypto amount, as an 8-decimal string.
`receivedCryptoAmount`	string \| null	What actually arrived, as an 8-decimal string.

What to do with an underpaid event — including the merchant review queue for payments that expire underpaid — is covered in the underpayments guide.

Reversal fields

In rare cases the payment partner reverses a payment after it has settled (for example an operator cancels the transaction on their side). The intent’s status stays settled — the crypto did arrive — but the payment.status event is re-emitted with two extra fields, and the payment then counts for nothing: it leaves the merchant balance, and an invoice it paid is open again.

{
  "type": "payment.status",
  "intentId": "pi_x7k2m9p4q1w8",
  "status": "settled",
  "amount": 49.90,
  "currency": "CHF",
  "assetSymbol": "USDT",
  "invoiceId": null,
  "paymentLinkId": null,
  "underpaid": false,
  "expectedCryptoAmount": "55.48765432",
  "receivedCryptoAmount": "55.48765432",
  "reversed": true,
  "reversedAt": "2026-07-08T09:58:41+00:00",
  "occurredAt": "2026-07-08T09:58:41+00:00"
}

Field	Type	Description
`reversed`	boolean	`true` once the payment has been reversed. A flag, not a status: `status` stays `settled`. Treat a reversed payment as not paid — undo fulfilment or contact the buyer.
`reversedAt`	string \| null	When the reversal was recorded. `null` on every event before a reversal.

Every payment.status event carries reversed (normally false) and reversedAt (normally null). The same two fields are on the intent returned by GET /api/v1/intents/{id}.

`ping`

Emitted when you press Send test event in the dashboard. It travels the same pipeline as real events — same signature scheme, same X-Qint-Event-Id header, same retry behavior. The full payload:

{
  "type": "ping",
  "endpointId": "3f2b8c1e-7a4d-4e9b-9c61-2d5f0a8e4b17",
  "sentAt": "2026-07-08T09:10:00+00:00"
}

Field	Type	Description
`type`	string	Always `ping`.
`endpointId`	string (UUID)	The id of the webhook endpoint the test was sent to — the endpoint you pressed the button on.
`sentAt`	string (ISO 8601)	When the test event was queued.

Verify it like any event, then return 2xx and ignore it.

Verifying signatures

Working verification code in four languages.

Delivery & retries

The retry schedule and the delivery log.

Overpayments and late deposits

There is no overpayment field or event. When a buyer sends more than the quoted amount, the payment settles normally and you receive the usual settled event. It is credited exactly like a normal payment — on the invoiced amount less Qint’s fee — so the excess is not added to your balance. Qint puts the payment in your dashboard’s review queue (reason “overpaid”) so you can refund the excess to the buyer off-platform and then acknowledge the item. The CSV export of your payments also has an overpaid column. See underpayments. A deposit that arrives after the payment window has expired also goes to the review queue. The intent stays expired until you decide; accepting it sends the normal settled event. Do not infer a successful payment from the presence of a deposit alone: use the API status and the review outcome. For XRP and XLM, display the checkout’s destination memo/tag as well as its address. An address alone may not identify the intended payment. Treat memo values as strings.

Getting started

Accept payments

Webhooks

Guides

Event types

`payment.status`

Credit fields

Underpayment fields

Reversal fields

`ping`

Verifying signatures

Delivery & retries

Overpayments and late deposits

​payment.status

​Credit fields

​Underpayment fields

​Reversal fields

​ping

​Related

Verifying signatures

Delivery & retries

​Overpayments and late deposits

`payment.status`

Credit fields

Underpayment fields

Reversal fields

`ping`

Related

Overpayments and late deposits