First, define what the chain has proved

A customer says the transfer is complete. The transaction is visible on chain, but the merchant’s order system still shows an unpaid sale. What should the team trust, and what should it change?

The safe answer starts by separating evidence from decision. A visible network transaction proves that a transfer with specific facts exists: asset, network, source, destination, amount and time. It does not, by itself, prove that the transfer belongs to this customer, this commercial obligation or this merchant-generated payment request. It also does not prove that the merchant’s acceptance conditions have been met or that fulfilment should begin.

That distinction prevents the two most damaging reactions. The first is telling the customer that nothing was paid because the business application has no record. The second is forcing the sale into a paid state because a screenshot or block explorer page looks convincing. Both reactions skip the missing connection between network evidence and the merchant’s internal payment decision.

Treat the incident as a broken chain of records:

commercial obligation → internal payment ID → provider request → network transaction → acceptance decision → fulfilment action

The investigation should find the last verified link, not rewrite the final state. Merchants designing an embedded flow can review the role of a crypto payment API, while teams using request-based collection can compare the records created by crypto invoices. In either model, the merchant’s own commercial reference remains essential.

Backend developer’s conclusion: “seen on chain” is an input to the merchant decision, not a substitute for that decision.

Use a triage matrix before anyone edits the sale

The first response should preserve evidence and reduce the chance of duplicate fulfilment. Support should acknowledge the customer’s report without promising that the sale is accepted. Engineering should avoid direct database edits. Finance should not create a manual receipt until the commercial reference and transfer evidence are connected.

Open one incident record and capture the customer account, sale reference, internal payment ID if known, provider request reference, transaction hash, destination, asset, network, received amount and observed time. Record where each fact came from. Customer-supplied evidence can help locate the transfer, but provider-side or server-side evidence should support the final automated decision.

Use this matrix to choose the next action:

What is known Immediate action What not to do
The internal payment record exists and the provider request is known Compare requested terms with received facts and inspect event delivery Do not create a second payment request for the same transfer
The transaction exists but no internal payment ID is known Search by destination, request reference and controlled time window; open manual review Do not match from amount alone
The provider shows an accepted payment but the business application did not update Inspect event receipt, validation, processing and state-write evidence Do not replay fulfilment blindly
The transfer uses an unexpected asset, network, amount or timing Hold the sale under the merchant’s exception policy Do not change expected terms to make the transfer appear valid
The sale is already fulfilled through another action Lock further fulfilment and investigate duplicate paths Do not “fix” the visible state before checking delivery history

Access should be narrow while the case is open. Support may need read access and a way to add customer context. Engineering may need event and state-change evidence. Finance may need the accepted-value decision and commercial document. A single person should own the incident, even if several teams contribute.

This is where ecommerce teams often discover that their customer-facing flow and their finance record use different identifiers. The ecommerce solution overview and the WooCommerce integration page are useful adjacent references, but the practical test is local: can the team move from the sale reference to one internal payment record without searching private messages?

Operational conclusion: the first objective is not to mark the sale paid. It is to preserve one reviewable case and stop competing fixes.

Follow the merchant checklist from the payment request outward

A useful checklist follows causality. Start with what the merchant created, then move toward what the network recorded and what the business application decided.

Check the commercial record

Confirm that the sale still exists and identify its immutable internal reference. Check the customer account, goods or service, amount policy, reference currency, expiry condition and current fulfilment state. If the sale was cancelled, replaced or merged, retain that history. Do not assume the newest record is the one the customer paid.

Check the internal payment ID

Find the payment ID generated for that commercial obligation. It should connect the sale to the provider request and later acceptance action. If several attempts exist, identify which attempt produced the destination and terms shown to the customer. A browser session ID, email address or transaction amount should not replace this binding record.

The adjacent guide on matching a crypto payment to the correct customer account explains why payer identity cannot be inferred safely from a transfer alone.

Compare requested terms with received facts

Keep the two sets separate. Requested terms include the expected asset, network, destination, amount rule and validity condition. Received facts include the actual asset, network, destination, amount and observed time. Differences are not necessarily losses, but they are exceptions that require a documented merchant decision.

Check the destination character by character from trusted system evidence. Confirm that the asset exists on the intended network rather than relying on a familiar ticker. Compare the received amount using the merchant’s configured precision and acceptance policy. Check whether the request was still valid under the policy that applied when it was created.

Check the provider record and acceptance condition

Locate the provider-side request using the stored provider reference, not a customer name. Determine whether the transfer is merely observed, still awaiting the merchant’s chosen acceptance condition, accepted, rejected or held for review. Provider terminology can vary, so map each provider state to the merchant’s internal states explicitly.

Do not make fulfilment depend on the customer returning to a browser success page. The customer may close the tab, lose connectivity or revisit the page. The authoritative path should be server-side and traceable.

Check event receipt and authenticity

Find evidence that the provider event reached the merchant endpoint. If there is no receipt, investigate routing, endpoint availability and delivery attempts. If the event arrived, verify that the application authenticated it using the provider’s documented method before reading it as trusted input. Preserve the event ID, request reference, received time and validation result without placing secrets in the incident record.

Check event processing and duplicate safety

A received event can fail after authentication. Trace parsing, schema validation, internal payment lookup, transition rules, database write and any queued work. Record whether the event was accepted, ignored as a repeat, rejected as invalid or moved to retry. A repeated valid event should converge on the same accepted payment record; it should not create another receipt or another fulfilment action.

Check the business-state write

The final write may fail because the target record is locked, missing, already in a conflicting state or blocked by a business rule. Compare the event decision with the persisted sale state. If a retry is safe, retry the specific state transition through the normal application path. Avoid a raw database edit that bypasses the incident log and downstream controls.

For the evidence finance should retain across these steps, use the payment evidence guide. For the close process after the incident, the finance matching guide provides related context.

Practical conclusion: the missing update is usually found at a boundary between records. Inspect every boundary in sequence rather than searching all logs for the transaction hash and hoping the answer appears.

Diagnose the failure boundary, not just the symptom

Once the checklist identifies the last successful link, classify the incident. Classification matters because different defects require different recovery actions.

Binding failure

The transfer cannot be connected to one internal payment ID. This may happen when the customer reused old instructions, paid from a shared corporate wallet without the expected reference, or created several similar attempts. The safe response is manual allocation with documented evidence and approval. Do not let an amount-and-time guess become a permanent automated rule.

Observation failure

The provider or merchant monitor has not associated the network transaction with the payment request. Recheck asset, network and destination before escalating. A transaction on another network can display a familiar token symbol while remaining unrelated to the requested route.

Acceptance failure

The transfer is known but does not meet the recorded rule. It may have arrived outside the validity condition or differ from the expected terms. The merchant needs an authorised commercial decision: accept, request an adjustment, arrange a return under policy or keep the case open. The technical team should not decide commercial acceptance by changing configuration retrospectively.

Delivery or validation failure

The provider has a decision, but the merchant did not receive or trust the event. Correct the endpoint, authentication or routing issue, then use a controlled provider-supported redelivery or a merchant-built recovery process. The recovery action must preserve the original event identity and remain duplicate-safe.

Processing failure

The event arrived and passed authentication, but application code failed before persistence. Retry from the failed step only if the operation is designed for repeats. If the code cannot prove whether a write occurred, inspect the durable record first; a second attempt must not create another customer credit.

Fulfilment failure

The accepted payment is recorded, but stock allocation, account access, licence delivery or service scheduling did not complete. This is no longer a payment-detection problem. Create or resume the fulfilment task using its own durable action key and retain the connection to the accepted payment.

A symptom-based response often replays the entire path and creates new ambiguity. A boundary-based response repairs the narrow failed handoff and proves the resulting state.

Engineering conclusion: recovery should begin immediately after the last durable success, not at the beginning of the flow and not at the final database field.

Work the exceptions without accidental fulfilment

The following microcases are hypothetical. They illustrate merchant controls and do not describe a customer, service result or product performance.

Microcase: the customer reused an expired payment request

A customer begins a purchase, leaves the payment page and later sends funds using saved instructions. The original sale has expired and a replacement sale now exists with different commercial terms. The transfer appears on chain, but the active sale has no matching payment decision.

Support should not attach the transfer to the replacement sale because the customer names it. The incident owner finds the original internal payment ID, confirms the destination and requested terms, then compares them with the received facts. An authorised commercial reviewer decides whether the old obligation can still be accepted, whether an adjustment is needed or whether the return policy applies. The original record remains expired; the later decision is added as a linked event.

The customer receives a clear explanation of what evidence is under review and what happens next. Guidance on reducing avoidable payer errors is available in the customer payment mistake guide.

What this exposes: a valid transfer can belong to a no-longer-active commercial obligation. Visibility is not permission to move it to the newest sale.

Microcase: accepted payment, failed access delivery

A business application receives an authenticated provider event and records the payment as accepted. The subsequent job that grants account access fails. The customer sees the network transaction, while a support screen still presents the overall sale as unpaid because it reads a combined “paid and delivered” field.

The team first checks the accepted payment record and confirms that the financial action exists once. It does not replay payment acceptance. Instead, it repairs the projection used by support and resumes the access-delivery task with a duplicate-safe action key. If access was already granted before the visible error, the retry reports success without granting it again.

What this exposes: combining payment and fulfilment into one visible field hides the real failure boundary. Separate states allow the team to recover the unfinished action without repeating the completed one.

Returns require the same separation. A return is a new authorised action connected to the original payment; it should not erase or reverse history through an edit. The merchant return policy guide covers the adjacent customer and finance decisions.

What merchant teams notice too late

Teams often prepare the happy path and leave recovery to whoever is online. The hidden cost then appears as support time, engineering interruption, finance research, delayed fulfilment, duplicate credits and corrections after close. Without verified benchmarks, a merchant can still measure its own operating cost:

incident cost = support handling + engineering diagnosis + finance review + customer communication + fulfilment correction + close adjustment

Track cases by failure boundary, not only by final outcome. Useful internal measures include the share of cases with no internal payment ID, time spent waiting for an owner, repeat-event handling results, manual state changes, duplicate fulfilment attempts and unresolved cases at close. These are management measures, not promises about provider performance.

Build a recovery runbook from the checklist:

Automation should stop when the system cannot prove a unique binding, trusted evidence, a permitted state transition and duplicate-safe effect. Manual review is not a failure of automation; it is the correct state for an ambiguous commercial decision. The merchant should also delay automation if its sale records do not have stable IDs, if staff routinely edit database states directly, or if payment and fulfilment cannot be inspected separately.

Crypto acceptance may not fit a particular sales path when the business cannot define who owns exceptions, how late or mismatched transfers are handled, or how returns are authorised. Existing methods may be sufficient when customers do not need another option and the added operating work has no clear business value. The local CryptoWay FAQ can provide product context, but each merchant still needs its own legal, accounting, tax and operational review.

The final incident close should answer a compact set of questions: Which obligation was paid? Which evidence supported the decision? Which rule was applied? Which state changed? Was the action safe to repeat? Did fulfilment occur exactly once? Can finance and support find the same record later?

Final conclusion: when a payment appears on chain but not in the order system, do not choose between the chain and the application. Connect them through the internal payment record, find the failed boundary, recover only the unfinished action and preserve the evidence that explains the decision.