Transaction detection, chain confirmation, order association and service delivery are separate steps. Verify the correct chain, asset, recipient and amount; apply a documented acceptance policy; and make reconciliation idempotent. A transaction reference, screenshot or browser button alone cannot establish that a specific order has been paid.
Separate the chain event from the order event
A wallet reporting that a transfer was sent is evidence about its own action, not a complete payment decision. The receiving backend must observe the intended network, verify the actual transfer and associate it with an order. Only then can the order apply its acceptance policy. Infrastructure delivery is another operational step after payment acceptance.
Keep these transitions explicit in both code and customer language. A screen can show waiting, detected or confirming without calling the order paid. Do not let the browser supply the accepted amount or overwrite an authoritative status. Store the server-created quote and its instructions so later reconciliation can be assessed against the original order rather than a changing cart.
Use chain-specific confidence rules
Different networks describe transaction confidence differently. Bitcoin's developer guide explains how nodes select the chain with the most accumulated proof of work and how competing blocks can occur. A transaction seen recently therefore needs a policy for confirmation depth and possible chain changes. There is no single confirmation count appropriate to every asset and commercial risk.
Ethereum's proof-of-stake documentation explains checkpoint finality, while Solana documents processed, confirmed and finalized commitment states. Do not translate those terms casually into one universal block count. Record the network-specific rule, information source and behaviour during uncertainty. The operator should determine acceptance thresholds against the payment and delivery risk, not copy a number from an unrelated checkout.
Verify the actual transfer payload
Identify the recipient, asset and amount on the correct chain. Token payments need the intended token identity, not merely a successful transaction to an address. Verify relevant execution success and transfer evidence according to the chain's model. Parse integer amounts at the asset's proper precision instead of trusting a formatted decimal supplied by the browser.
A payment instruction must remain bound to its original route. A transfer on another network, a different token with the same symbol or an unrelated transaction reference should not satisfy it. The verification record should explain what was checked and preserve the evidence needed to review the decision. This guide describes general payment-reconciliation principles rather than a particular service implementation.
Make order association unambiguous
Fixed receiving addresses can receive several orders with similar amounts. The existence of a matching transfer does not prove which customer or order should receive credit. Define the association method before accepting live payments and include handling for collisions. A user-supplied transaction reference still requires validation that the same transfer has not already been assigned elsewhere.
Imagine two invoices for the same amount on the same route during an overlapping window. A watcher sees one transfer. Automatically marking both paid is wrong; choosing one without enough evidence is also unsafe. Keep the transfer unallocated or in review until the operator's policy can establish a valid association. An ambiguous match is a state to handle, not a reason to fabricate certainty.
Define states that tolerate late and changing evidence
A payment process benefits from a small set of clear states, with chain evidence separate from the decision to accept an order. This illustrative table explains possible stages rather than describing a particular service's status names. Each transition should have a verified reason, and payment acceptance should remain distinct from infrastructure delivery.
Include late, partial and excess transfers, quote expiry and temporarily unavailable chain data. Expiry does not make a real transfer disappear. A late payment may require review rather than automatic acceptance or rejection. If a previously observed chain event changes, re-evaluate the state under the documented policy instead of treating every watcher notification as irreversible truth.
| Illustrative state | Meaning | Next decision |
|---|---|---|
| Awaiting | No verified qualifying transfer | Continue observing valid invoice |
| Detected | Relevant transfer observed | Check chain confidence and association |
| Confirming | Acceptance rule not yet met | Observe until policy permits decision |
| Review | Late, partial or ambiguous evidence | Resolve under operator policy |
| Accepted | Verified and reconciled payment | Proceed to separate delivery workflow |
Make retries safe and observable
Watchers and reconciliation jobs will retry after interrupted connections or process restarts. Use a stable transfer identity, such as the chain and the appropriate transaction or transfer identifier, to prevent duplicate credits. Persist progress and decisions so the same event can be processed again without provisioning a second service or changing an accepted quote.
Distinguish an unknown result from a failed operation. If a downstream request times out, inspect its authoritative result before resubmitting. Keep durable records of accepted and uncertain actions. Restrict access to order tokens and internal evidence while retaining enough information to investigate a disputed payment. Reliability here is about repeatable decisions, not a smooth animation in the checkout.
Know what a pending order still needs
An order may remain pending because the transfer has not been observed, the required chain confidence has not been reached or its association with the invoice needs review. Preserve the invoice and public transaction reference, check the stated acceptance rules and use the order's intended assistance process. A delayed status update is not, by itself, a reason to send another payment.
Follow the instructions and verified status for the actual order. Payment confirmation should identify acceptance of the reconciled transfer, while service delivery has a separate status. Keep private access tokens and wallet secrets out of requests for help.
Your practical checklist.
- Persist an immutable server-created quote.
- Verify chain, recipient, asset and integer amount.
- Document chain-specific acceptance rules.
- Handle fixed-address collisions without guessing.
- Prevent duplicate credits and unsafe retry submissions.
- Test late, partial, wrong-route and changed-evidence cases.
The details that matter.
Is a transaction hash enough to confirm payment?+
No. Verify the transfer on the intended chain, its payload and confidence, then establish that it belongs to the order and has not already been credited.
Can every network use the same confirmation threshold?+
No. Networks expose different confidence and finality models. The operator must define and test an acceptance policy appropriate to each route.
Does confirmed payment mean the server is provisioned?+
No. Payment acceptance and delivery are separate workflow events. Communicate provisioning status from its own authoritative process.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Bitcoin developer guide: Blockchain behaviour developer.bitcoin.org
- Ethereum: Proof of stake and finality ethereum.org
- Solana: RPC state commitment solana.com
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.