> For the complete documentation index, see [llms.txt](https://kreatorverse-2.gitbook.io/kollect-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kreatorverse-2.gitbook.io/kollect-documentation/reference.md).

# Reference

Payment records use a fixed set of **string statuses** stored on the Kollect payment model. Webhook payloads echo the post-update **`status`** field.

## Status values

The `Payment` model enforces exactly **four** status values — this is the full set:

| Status      | Meaning                                             |
| ----------- | --------------------------------------------------- |
| `created`   | Payment row created.                                |
| `submitted` | Intermediate / submitted state on chain or gateway. |
| `success`   | Payment confirmed (after `payment.confirmed`).      |
| `failed`    | Payment failed (after `payment.failed`).            |

## Invoice correlation

When a payment succeeds, the related **invoice** may be updated to **`paid`** as part of webhook processing. Exact business rules follow the Kollect services that handle the Smart Contract callback.

## Polling alternatives

Two status-polling endpoints exist; pick the one matching your integration surface:

| Endpoint                            | Auth                                               | Who it's for                                                                                                |
| ----------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `GET /sdk/server/status/:paymentId` | API key + secret (same S2S auth as create-payment) | **Server integrations.** No DPoP required — poll from your backend on behalf of the payer.                  |
| `GET /sdk/status/:paymentId`        | Session token + **DPoP** proof                     | Browser/mobile SDK sessions polling on behalf of a logged-in user. Not part of the API-key + HMAC S2S flow. |

For server integrations, **webhooks are still the preferred mechanism** for fulfillment (they push, so you don't need a polling loop) — but `GET /sdk/server/status/:paymentId` is available for reconciliation or for merchants who haven't set up a webhook yet.

## Related pages

* [Payment lifecycle](/kollect-documentation/introduction/architecture-and-data-flow.md)
* [Webhooks overview](/kollect-documentation/webhook-overview.md)