Crypto Payment Intermediate State

Overview

What it means and why it matters

An intermediate payment state records a meaningful stage between creating a payment and reaching a terminal outcome. It makes complex workflows explainable and auditable.

How it works in practice

A payment may progress through created, awaiting transfer, detected, confirming, underpaid, manually reviewing and paid. Intermediate stages record which conditions have already been met. Systems choose their own vocabulary, but transitions should be defined as a state machine with explicit triggers and permitted next states.

Technical detail without the jargon

State transitions need event IDs, timestamps, source evidence and versioning. A late webhook can arrive after a newer event; if it blindly overwrites current state, a paid invoice may incorrectly revert to pending. Enforce state-order rules rather than trusting message arrival order.

A deeper point to understand

State names are less important than the invariants they enforce. For example, detected cannot imply accepted; refunded cannot be reached without a refund operation; paid can only authorize fulfillment once. A state machine should also define what happens when contradictory evidence arrives, including a chain reorganization or a provider correction.

Common mistakes and limitations

Too many ambiguous intermediate labels confuse merchants. Too few hide operational problems. Provide clear human labels while retaining specific machine-readable reason codes and transfer histories.

What to check in a real payment system

Write down allowed state transitions and their triggers, then test callbacks arriving in reverse chronological order. Persist the latest accepted state version atomically. A manual-review transition needs a reason code and reviewer identity rather than an unexplained status change.

Related concepts

Crypto Payment Status, Crypto Invoice, Transaction Finality.

Further reading

OxaPay — API Documentation.