Payment lifecycle

Maxana publishes separate state vocabularies for checkout sessions, transactions, and text-to-pay requests. Do not compare values across registries as if they represented one state machine.

Registry	Contract values
Checkout session	open, order_created, processing, completed, expired, canceled
Transaction	created, approved, captured, refunded, disputed, failed, voided, other
Text to pay	sending, pending, completed, expired, canceled, failed

Persist the raw status you received and make handlers tolerant of values your business logic does not yet recognize. Use the registry documented by the resource being processed, and reconcile asynchronous changes through the resource API and webhooks.

An approval is not the same as a capture. A browser callback is not settlement evidence. Fulfil only from the transaction state your business has chosen as final, and define separate handling for refunds, disputes, failures, voids, and unknown provider states.

Current limits

The three status registries do not form one universal ordered state machine. Approval and a browser return are not settlement evidence, and one webhook does not guarantee that no later provider transition will follow.