What is idempotency in a ledger?

Idempotency means sending the same request twice produces one movement, not two. In a ledger that is a unique reference on the transaction. Timeouts, retries, and double clicks all resend work. The reference is what stops the second post from becoming a second credit.

How does idempotency work?

Your app creates a key before it calls the API. The ledger stores that key on the first success. A second call with the same key returns the first transaction. A new movement needs a new key. HTTP 200 on a retry is success, not a second credit.

Idempotency vs immutability

Idempotency stops duplicates at the door. Immutability stops edits after the fact. You need both. A unique reference without an immutable log still lets someone “fix” a row. An immutable log without a reference still accepts two posts for one click.

Where do keys come from?

The job id, the checkout attempt, the webhook delivery id. Generate the key in your system, not in the ledger. Do not reuse a payment reference for the refund. The refund is a different movement.

Blnk requires a reference on every transaction and treats it as the idempotency key. Read the idempotency guide for the retry cases, then put the reference in your worker before you call the API.