Crypto Payment Paid State

Overview

What it means and why it matters

The paid state is the payment system’s conclusion that sufficient valid funds have been received under an invoice’s acceptance rules. It is a business status, not merely a wallet notification.

How it works in practice

The service groups transfers that belong to the invoice, verifies each asset and network, checks successful execution and finality policy, then compares the accepted amount against the invoice obligation. It stores the accepted outcome and notifies the merchant. Fulfillment can begin based on the merchant’s risk policy.

Technical detail without the jargon

The rule may allow partial payments within a documented underpayment tolerance or reject overpayment until manual reconciliation. The paid transition should be idempotent: replayed callbacks must not trigger a second order shipment, and a payment update should not erase the underlying transfer audit trail.

A deeper point to understand

An invoice can be paid through several token transfers but have only one paid transition. When refunding, the system needs the original accepted components to calculate the correct amount and currency. Treat paid as a durable outcome with correction events, not a label that can be switched back and forth by arriving callbacks.

Common mistakes and limitations

A deposit to the correct address can still be an incorrect asset, wrong contract, reversed transfer, or insufficient amount. Avoid setting paid directly from a customer-supplied transaction hash or screenshot.

What to check in a real payment system

Before turning on fulfillment, trace each contributing transfer to a specific invoice and compare accepted base-unit amounts with the expected obligation. Execute the fulfillment function twice with the same paid event during testing: the second invocation must have no additional business effect.

Related concepts

Crypto Payment Status, Crypto Invoice, Transaction Finality.

Further reading

OxaPay — API Documentation.