Should Paid mean books-ready?

Only if finance policy explicitly says so. Many merchants allow Paid for low-risk signals while treasury waits for Confirmed and reconciliation matchers.

How do matchers handle delays?

Use time-bounded windows and timing-skew exception classes rather than failing hard immediately on first mismatch.

What about customer refunds during delay?

Refund policy should reference lifecycle state and exception ownership—avoid refunds that contradict later Confirmed events without investigation.

Does Kobbopay guarantee confirmation times?

No. Public materials describe lifecycle semantics bounded to configured rails—timing remains environment and policy specific.

Reconciliation & operations

Reconciling Asynchronous Settlement Systems

Async settlement is normal. Reconciliation breaks when intermediate states are invisible or when teams pretend one paid flag means everything is final.

6 min readOperational journal

Operational summary

Explains reconciling delayed settlement with intermediate lifecycle states, timing-skew exceptions, and finance holds—not single paid flags.

Topical cluster

Reconciliation

Knowledge map Research index

Article relationships

Prerequisite reading

Reliable reconciliation flows

Baseline reconciliation framing.

Related operational concepts

Asynchronous settlement
Timing skew
Intermediate states
Finance holds
Period close

Operational Evidence Collection in Crypto Payment Reconciliation — Evidence during long delays.

Asynchronous settlement separates detection, policy confirmation, and treasury recognition in time. Reconciliation systems that only compare end states will misclassify healthy delays as errors—and healthy errors as matched payments.

Represent intermediate truth

Provider plane should expose states finance recognizes: detected, policy-pending, confirmed, failed, expired. Finance plane should expose unrecognized, recognized, posted, held. Commerce should not claim fulfilled-at-paid unless policy allows.

Timing-skew as a first-class exception

When Confirmed arrives before Paid during incidents, handlers must no-op safely. When Paid sits without Confirmed beyond threshold, open timing-skew—not silent support overrides.

Closing periods with async volume

Month-end close should include aging analysis on intermediate states. Carry forward timing-skew with evidence rather than forcing match to hit an arbitrary deadline.

Frequently asked questions

Should Paid mean books-ready?: Only if finance policy explicitly says so. Many merchants allow Paid for low-risk signals while treasury waits for Confirmed and reconciliation matchers.
How do matchers handle delays?: Use time-bounded windows and timing-skew exception classes rather than failing hard immediately on first mismatch.
What about customer refunds during delay?: Refund policy should reference lifecycle state and exception ownership—avoid refunds that contradict later Confirmed events without investigation.
Does Kobbopay guarantee confirmation times?: No. Public materials describe lifecycle semantics bounded to configured rails—timing remains environment and policy specific.

Operational references

Related guides

Lifecycle decision tree

Glossary

Asynchronous settlement

Operational concepts

Infrastructure references

Integration references
Design models.
Research index
Curated operational research and reading order.
Knowledge map
Topical cluster graph for concepts, hubs, and guides.
Playbooks
Operational workflow procedures for payment teams.
Observability
Signal catalog and dashboard concepts for payment operations.
Incident taxonomy
Signal-to-playbook routing for operational incidents.