---
title: "Withdrawal status"
description: "Explain a pending payout without submitting the same withdrawal twice."
category: "Guides"
---

A pending provider response is a distinct state from a failed request. This pattern tracks an existing payout; it does not teach payment initiation or implement identity and risk decisions.

## Separate checks from confirmation

Define steps for validating the withdrawal reference, reading completed player verification, applying your risk decision, reconciling the existing payout, and notifying the player.

Your domain services own each business decision. A stage should return a useful status and correlation reference rather than a vague “OK”. A terminal business rejection should not enter an automatic retry loop.

## Reconcile an existing payout

The confirmation handler reads the provider using the payout reference. Treat outcomes explicitly:

| Provider outcome | Handler behavior |
| --- | --- |
| Confirmed | Record the confirmed reference and allow notification |
| Definitively rejected | Record the reason permitted for support; stop or follow your rejection path |
| Pending | Report a classified transient condition and use bounded retry settings |
| Timeout or lost connection | Query again using the same reference; do not infer failure |
| Reference missing or inconsistent | Escalate for reconciliation rather than creating a replacement payout |

Pipelogiq's retry delay is useful for bounded status checks. There is no generic delayed-stage timer to assume here. For periodic reconciliation outside one execution, use a [schedule](/docs/schedules).

## Keep the customer answer specific

Support should be able to see which checks finished, when the last confirmation check ran, and whether another check is planned. Do not turn an integration timeout into a claim that the customer's money is lost.

The home-page example says that the checks are complete and confirmation is pending. It is a fictional illustration of the context your handlers should expose. It is not connected to a provider.

## Confirmations and cancellation

An approval-waiting stage and a provider-pending status check are different mechanisms. Approval waits for an explicit API decision; a provider check executes a handler again. See [reliable execution](/docs/reliability).

Cancelling a pipeline stops further orchestrated work and invalidates unfinished execution attempts. It does not reverse a payout already started by an external service. Implement any reversal as an explicit, authorized business operation with its own reconciliation rules.

## Implement and verify

Use the [.NET recipes](/docs/net/workflows) or [Java recipes](/docs/java/workflows) for error classification, context, and idempotency. Test confirmed, rejected, pending, and unknown outcomes. Assert that retries keep the same external payout reference and never submit a new payout.