+++
title = "Exactly-once delivery and exactly-once financial effects"
description = "Delivering an event once and applying its financial effect once are different guarantees. Explore retries, deduplication and ledger boundaries."
date = 2026-09-11
draft = false
[taxonomies]
topics = ["brokers-queues-event-transport", "streaming-event-processing", "payment-gateways-rails-orchestration", "core-ledgers-account-processing"]
kinds = ["advanced-explainer"]
[extra]
tier = "public"
schema_type = "Article"
article_class = "advanced-explainer"
related_concepts = ["idempotency", "acknowledgement", "transaction boundary", "replay"]
sources = ["https://www.rabbitmq.com/docs/confirms", "https://kafka.apache.org/41/design/design/", "https://docs.stripe.com/api/idempotent_requests?lang=curl", "https://www.postgresql.org/docs/current/transaction-iso.html"]
source_details = [{ title = "Consumer Acknowledgements and Publisher Confirms", publisher = "RabbitMQ Project", url = "https://www.rabbitmq.com/docs/confirms", checked = "2026-09-09" }, { title = "Design — Apache Kafka 4.1", publisher = "Apache Software Foundation", url = "https://kafka.apache.org/41/design/design/", checked = "2026-09-09" }, { title = "Idempotent requests", publisher = "Stripe", url = "https://docs.stripe.com/api/idempotent_requests?lang=curl", checked = "2026-09-09" }, { title = "Transaction Isolation", publisher = "PostgreSQL Global Development Group", url = "https://www.postgresql.org/docs/current/transaction-iso.html", checked = "2026-09-09" }]
faq = [{ question = "Does exactly-once stream processing guarantee exactly-once payments?", answer = "No. The guarantee must include the payment effect or a separate mechanism that prevents or reconciles repeated effects." }, { question = "Is a unique message identifier enough?", answer = "No. The identifier must represent the stable business instruction, and its duplicate check must be connected to the financial commit." }, { question = "Does a timeout prove the payment failed?", answer = "No. A timeout can occur after an external effect commits but before its response reaches the caller." }]
evidence_as_of = "2026-09-09"
related_articles = ["financial-database-roles", "recovery-transaction-reconciliation", "trading-shutdown-completeness"]
category_slug = "software-models"
category_name = "Software & models"
+++

Exactly-once financial processing means that one identified business instruction produces one intended financial effect within a defined processing boundary. Message delivery, processor-state recovery and an external ledger commit are separate events whose guarantees must be connected.

## Publication, consumption and financial commitment

A publisher confirmation establishes an outcome on the publishing leg of a messaging system. A consumer acknowledgement establishes an outcome on the consumption leg. RabbitMQ explicitly separates those mechanisms: a publisher confirmation does not know the consumer’s business state.

Kafka similarly distinguishes publication and consumption guarantees. A transactional processing guarantee covers the operations included in its documented transaction boundary. An external payment service or ledger does not become part of that boundary merely because a consumer calls it.

The business effect needs its own authoritative record. For a posting, that record identifies the instruction and the committed accounting operation. For an external payment, the relevant provider record and later events can form additional reconciliation boundaries.

## A crash after the posting commits

Take one instruction to credit 100 dollars, with an equal balancing entry elsewhere in the ledger. The worker submits the posting, the ledger commits and the worker crashes before acknowledging the consumed message. The broker then redelivers the instruction.

The redelivered message does not represent a second business request. If the worker inserts another complete posting without recognizing the original instruction, the target account receives 200 dollars from two executions of one request. Both sets of ledger entries could balance internally while the business effect is wrong.

A safe replay instead resolves the stable instruction identifier to the already committed posting. The account retains one 100-dollar effect and the caller can recover the operation’s recorded outcome. The identifier must survive the retry; generating a new one on every delivery discards the relationship the check depends on.

## Atomic effect and deduplication state

A duplicate check needs to be coupled to the financial commit. Consider a separate record saying an instruction has been processed. Writing that record before the posting creates a crash interval in which replay can skip an effect that never happened. Writing it after the posting creates an interval in which replay can repeat an effect that already happened.

When both records are controlled by one transactional store, an atomic operation can couple instruction uniqueness to the intended posting. The application still needs to implement the correct posting and concurrency behavior. A transaction cannot identify a duplicated business request unless the application supplies the right identity and constraint.

When the effect lies outside the local transaction, the design needs a documented coordination, idempotency or reconciliation path. An uncertain response cannot safely be converted into either definitely failed or definitely completed without evidence from that path.

## Idempotency scope and replay lifetime

An idempotency key identifies a repeated operation under a particular endpoint’s rules. Stripe’s documented mechanism replays a stored result for later requests with the same key, subject to execution, parameter and retention conditions. It is not a permanent guarantee covering every downstream system.

Replay policy must therefore preserve both identity and the period over which an earlier effect can still be recognized. A retry after deduplication evidence has expired requires a different justification from a retry within the documented window.

## Scope of exactly-once claims

The claim becomes meaningful when it names the business instruction, authoritative effect, commit boundary, failure intervals and recovery evidence. Duplicate delivery can coexist with one financial effect. Conversely, an internally consistent processor can coexist with a duplicated external effect if that effect falls outside its guarantee.

## Questions about idempotency

### Does exactly-once stream processing guarantee exactly-once payments?

No. The guarantee must include the payment effect or a separate mechanism that prevents or reconciles repeated effects.

### Is a unique message identifier enough?

No. The identifier must represent the stable business instruction, and its duplicate check must be connected to the financial commit.

### Does a timeout prove the payment failed?

No. A timeout can occur after an external effect commits but before its response reaches the caller.