Payment workflow and statuses

This guide explains payment status workflows: card and alternative payment method (APM) processing, authorization, capture, void, refund, and their intermediate or terminal outcomes.

Use payment.data.status as the payment-state field. In a response or webhook that wraps the payment inside an order, its full path is order.payment.data.status. The order container does not change the meaning of this payment field.

Use the payment status together with confirmed amounts and operation history. A successful HTTP request does not always mean that the financial operation has completed.

When to use order.status: Only use order.status when the merchant deliberately uses DEUNA's order to simulate a shopping cart. For that use case, consult the Implementation Manager or Pre-Sales Engineer about the appropriate order lifecycle. This guide covers payment status workflows, not shopping-cart or order-status workflows.

Card and APM workflows are documented separately below. For fraud decisions, see Fraud Workflow and Statuses.

The diagrams show applicable paths, not a mandatory sequence of notifications. Available operations depend on the payment method and processor connection.

On this page

• How to interpret a status
• Card payment workflow
• APM payment workflow
• Payment status reference
• Payments and payment operations
• Synchronous and asynchronous processing
• Authorization, capture, and void
• Refunds and partial refunds
• Denials, expiration, and cancellations
• Handling payment updates

How to interpret a status

The following categories are documentation labels, not additional API fields.

For this guide, denied, expired, refunded, and voided are terminal outcomes. Treat a denial as an unsuccessful final result. It has no recovery path. The 3DS diagram includes denial when authentication fails or the customer declines the challenge.

authorized, processed, captured, partial_captured, and partial_refunded are successful but nonterminal. Authorization is not capture, and a captured or processed payment can still be refunded.

A partial result can complete the merchant's workflow. partial_captured and partial_refunded can be the last observed payment state when the merchant does not intend to capture or refund the full amount. They are conditionally final for the merchant's business process, rather than universally terminal API statuses. No further transition is required merely because a balance remains.

For example, a merchant can capture USD 60 of a USD 100 authorization and close further captures with final_capture: true, or refund only USD 20 of a USD 100 purchase. Once the intended operation is confirmed and no operation remains pending, the merchant can mark that business process complete. Keep the actual payment status and confirmed amounts; do not change a partial status to captured or refunded locally to indicate business completion. Closing captures does not prevent an otherwise eligible refund.

The partial states remain blue in the diagrams because further operations can still be eligible. The diagrams show possible transitions, not a requirement to consume the full authorized or refundable amount.

Payment records, processing attempts, and individual capture/refund operations have different lifecycles. Merchants do not necessarily receive a notification for every intermediate state. Disputes, chargebacks, and accounting adjustments are outside this guide's scope.

Card payment workflow

Read one operation at a time. Each panel has its own starting state and uses short, forward-only branches. Repeated status labels represent the same API value, not separate payments. A processor can return success directly or expose an intermediate state before confirmation.

Purchase: single-step payment

flowchart TD
    start["pending"]
    sync["processed"]
    wait["processing"]
    ok["processed"]
    cancel["cancelled"]
    cancel2["cancelled"]
    start -->|"Immediate confirmation"| sync
    start -->|"Asynchronous result"| wait
    start -->|"Supported cancellation"| cancel
    wait -->|"Confirmed"| ok
    wait -->|"Supported cancellation"| cancel2
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class start,wait transient;
    class sync,ok success;
    class cancel,cancel2 exception;

Cancellation is available only for supported payment methods and configured processing flows. Use the reported payment status and prior financial activity to determine whether any reversal remains pending.

Authorization: two-step payment

flowchart TD
    start["pending"]
    sync["authorized"]
    wait["authorizing"]
    ok["authorized"]
    cancel["cancelled"]
    cancel2["cancelled"]
    start -->|"Immediate confirmation"| sync
    start -->|"Asynchronous result"| wait
    start -->|"Supported cancellation"| cancel
    wait -->|"Confirmed"| ok
    wait -->|"Supported cancellation"| cancel2
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class start,wait transient;
    class sync,ok success;
    class cancel,cancel2 exception;

3DS authentication

Authentication success continues to the financial operation. It does not, by itself, prove purchase or authorization success. Read the subsequent payment result.

Entry and unsuccessful outcomes

flowchart TD
    p["pending"]
    t["pending_3ds"]
    e(["expired<br/>TERMINAL"])
    c(["denied<br/>TERMINAL"])
    p -->|"3DS required"| t
    t -->|"Issuer challenge<br/>time limit"| e
    t -->|"Customer declines<br/>authentication"| c
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class p,t transient;
    classDef expiration fill:#ECEFF3,stroke:#586779,color:#172B4D,stroke-width:2px;
    class e expiration;
    classDef denial fill:#FDE8E7,stroke:#B42318,color:#713B12,stroke-width:2px;
    class c denial;

Successful continuation: purchase or authorization

After successful authentication, the processor connection determines whether DEUNA completes a single-step purchase or obtains an authorization for later capture.

flowchart TD
    t["pending_3ds"]
    p["processing"]
    ps["processed"]
    pd["processed"]
    a["authorizing"]
    as["authorized"]
    ad["authorized"]
    t -->|"Purchase pending"| p
    p -->|"Confirmed"| ps
    t -->|"Purchase confirmed"| pd
    t -->|"Authorization pending"| a
    a -->|"Confirmed"| as
    t -->|"Authorization<br/>confirmed"| ad
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class t,p,a transient;
    class ps,pd,as,ad success;

A 3DS challenge follows the issuer's authentication time limits. These are separate from the DEUNA APM payment deadline. Use the reported payment.data.status; elapsed browser time alone does not establish expired.

Full capture

Continue from a valid authorization. Both success branches report captured.

flowchart TB
    start["authorized"]
    sync["captured"]
    work["capturing"]
    ok["captured"]
    start -->|"Immediate capture"| sync
    start -->|"Capture pending"| work
    work -->|"Confirmed"| ok
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class start,sync,ok success;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;

First partial capture

A confirmed partial capture can be the last intended capture or can be followed by another eligible capture.

flowchart TB
    start["authorized"]
    sync["partial_captured"]
    work["partial_capturing"]
    ok["partial_captured"]
    full["captured"]
    start -->|"Immediate partial<br/>capture"| sync
    start -->|"Partial capture<br/>pending"| work
    work -->|"Partial amount<br/>confirmed"| ok
    work -->|"Capture completes"| full
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class start,sync,ok,full success;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;

Another partial capture

Start this panel only when another capture is needed and remains eligible. The repeated partial_captured label means another partial capture has completed. This view replaces a backward loop with a forward path.

flowchart TB
    start["partial_captured"]
    work["partial_capturing"]
    part["partial_captured"]
    full["captured"]
    start -->|"Next partial capture"| work
    work -->|"Partial amount<br/>confirmed"| part
    work -->|"Capture completes"| full
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class start,part,full success;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;

Processor support, remaining authorization, and the final-capture control determine eligibility. See Multiple partial captures for the execution modes, and Capture and void exceptions for unsuccessful operations.

Void

A void releases an eligible authorization. It does not refund previously collected funds.

flowchart TB
    start["authorized"]
    sync(["voided<br/>TERMINAL"])
    work["voiding"]
    ok(["voided<br/>TERMINAL"])
    start -->|"Immediate void"| sync
    start -->|"Void pending"| work
    work -->|"Confirmed"| ok
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class start success;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    class sync,ok terminal;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;

Refunds after payment

From processed, captured, or an eligible partial_captured payment, use the full and partial refund panels. Those panels are shared by cards and supported APMs, so refund arrows do not cross capture or void paths here.

APM payment workflow

An APM can complete directly from pending or expose processing before its final result. Cancellation depends on the selected method and supported provider flow. Repeated outcomes keep the branches separate; they represent the same status values.

flowchart TD
    p["pending"]
    w["processing"]
    ok["processed"]
    expiry(["expired<br/>TERMINAL"])
    cancel["cancelled"]
    ok2["processed"]
    expiry2(["expired<br/>TERMINAL"])
    cancel2["cancelled"]
    p -->|"Confirmation pending"| w
    w -->|"Confirmed"| ok2
    w -->|"DEUNA deadline"| expiry2
    w -->|"Supported<br/>cancellation"| cancel2
    p -->|"Confirmed"| ok
    p -->|"DEUNA deadline"| expiry
    p -->|"Supported<br/>cancellation"| cancel
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef expiration fill:#EDF0F4,stroke:#5B6573,color:#303C4D,stroke-width:2px;
    classDef cancellation fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class p,w transient;
    class ok,ok2 success;
    class expiry,expiry2 expiration;
    class cancel,cancel2 cancellation;

A redirect return, QR interaction, or customer action is not proof of payment. Wait for the authoritative payment outcome. No transition leaves denied or expired in this guide.

APM payment deadline: Configure in DEUNA the maximum time the customer has to pay. An unfinished APM payment can move from pending or processing to expired at that deadline. Use the reported payment.data.status; a browser timer, lost response, or missing webhook is not proof of expiration.

Keep the provider deadline earlier: Configure the provider's expiration time a few minutes before DEUNA's expiration time. This buffer helps prevent DEUNA from expiring a payment while the provider still allows the customer to pay successfully. Align the actual expiry timestamps, timezone, and timing rules with the Implementation Manager or Pre-Sales Engineer. The buffer reduces the race; it does not replace handling delayed confirmations and reconciliation.

After processed, use the refund panels only if the method supports them. Refund availability and partial-refund support depend on the configured provider.

Selected APMs: authorization and capture

Selected APMs only — for example, PayPal Wallet: Separate authorization and capture is an exception among APMs. Use the authorization and capture panels only when the selected method and processor connection support that model. PayPal documents its two-step capability in its authorize and capture guide.

Check partial captures, refunds, and voids separately. Authorization/capture support does not imply support for every card operation. The customer-payment deadline above does not expire an already authorized payment.

Payment status reference

Values are case-sensitive strings. Use the exact lowercase values shown below.

Payments and payment operations

A payment can have several related financial operations. For example, one authorization can be followed by multiple captures and multiple refunds. The current payment status and an individual operation's result answer different questions.

For example, the following payment excerpt confirms authorization, not capture:

{
  "order": {
    "payment": {
      "data": {
        "status": "authorized"
      }
    }
  }
}

The following capture response excerpt reports an operation in progress:

{
  "data": {
    "capture_id": "fffda815-bde4-47be-b698-f94ad41c270f",
    "status": "capturing",
    "capture_amount": {
      "amount": "2500",
      "currency": "USD"
    }
  }
}

These are excerpts, not complete payloads. Do not copy operation-level data.status into the payment lifecycle without applying the actual payment update. No sub_status field is introduced by this reference.

Synchronous and asynchronous processing

Synchronous outcomes

A processor can complete an operation during the request. Intermediate states can therefore be absent from the merchant's observations.

Examples include pending → processed, authorized → captured, authorized → voided, and processed → refunded. A direct transition does not imply that the financial steps were skipped; it means their intermediate states were not exposed to the merchant.

Asynchronous outcomes

An asynchronous operation first reports that processing is pending. A later provider result updates the payment and/or operation. Typical examples include:

For APMs, the customer can finish a redirect or other interaction before the provider confirms payment. Keep the payment pending until its authoritative result arrives.

There is no universal pending-state duration established by this reference. Use the documented processor timing and the merchant's reconciliation process instead of assuming that a timeout means failure.

Why an operation remains in an “-ing” status

A common reason for processing, capturing, partial_capturing, refunding, or partial_refunding is a batch-based settlement integration. DEUNA submits the applicable operations in a settlement file or batch, often at an end-of-day cutoff, and must wait for the corresponding processing result. Examples include applicable DEUNA integrations with AMEX, BBVA, Elavon, and UATP. These examples refer to configured batch flows, not every product or connection offered by those providers.

An accepted request or a submitted file does not by itself confirm the financial outcome. Keep the operation pending until the applicable confirmation arrives. A batch rejection can instead produce the failure behavior documented below.

An “-ing” suffix does not always mean end-of-day settlement. authorizing, for example, can mean that an authorization decision is still pending. Online asynchronous processing and delayed provider callbacks can also expose intermediate states. Use the configured processor schedule, cutoff, timezone, and confirmation rules; do not infer a fixed 24-hour wait from the status alone.

Business acceptance of pending settlement: Many merchants treat applicable batch-settlement “-ing” statuses as sufficient business success because settlement failure is considered extremely unlikely in their configured flows. This is a merchant acceptance or fulfillment policy; the financial operation is still technically pending. Consult the Implementation Manager or Pre-Sales Engineer before making this assumption. Do not apply it automatically to every intermediate status, particularly a pending authorization or unfinished APM payment. Continue to process final confirmations, failures, and reconciliation updates.

Authorization, capture, and void

Authorization

Choose single-step purchase or two-step authorization and capture at the processor connection level in the DEUNA Merchant Portal, when connecting or configuring the processor. Purchase V2 follows that connection configuration. For the two-step flow, a successful authorization is followed by a separate eligible capture request.

After authorized, request an eligible capture when funds should be collected, or an eligible void when the authorization is no longer needed. The payment status is only one eligibility input; processor rules and remaining amounts also apply.

Multiple partial captures

Use acquirer-native or processor-native multiple partial capture when the provider supports the required flow. DEUNA aggregation is the fallback for unsupported native flows.

Confirm the configured mode: Use native multiple partial captures when the provider supports the required flow. Confirm connection settings, submission timing, and any agreed aggregation mode with the Implementation Manager or Pre-Sales Engineer.

For activation, operating modes, cutoff rules, and examples, see MPC — Multiple Partial Captures. This guide focuses on status handling.

final_capture: true closes further captures under the configured MPC rules. It does not prove that capture has completed or that the captured amount equals the full authorization. Keep requested, pending, and confirmed capture amounts separate. Follow the configured timezone, submission conditions, and confirmation results.

Void

The native Void API applies to eligible authorizations and returns HTTP 204 No Content on success. A flow can expose authorized → voiding → voided, or a direct authorized → voided transition.

A refund returns previously collected funds. A void releases an eligible authorization. These operations are not interchangeable solely because both reverse a previous financial step.

Capture and void exceptions

A failed capture does not automatically invalidate the original authorization. Read the operation result and the payment update separately.

Full capture recovery

flowchart TD
    c["capturing"]
    a["authorized"]
    c -->|"All captures fail;<br/>authorization retained"| a
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class c transient;
    class a success;

Partial capture recovery

flowchart TD
    c["partial_capturing"]
    a["authorized"]
    p["partial_captured"]
    c -->|"All captures fail;<br/>authorization retained"| a
    c -->|"Earlier captures<br/>remain confirmed"| p
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class c transient;
    class a,p success;

Void recovery

flowchart TD
    v["voiding"]
    a["authorized"]
    v -->|"Authorization retained"| a
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class v transient;
    class a success;

These arrows describe possible outcomes, not permission to repeat an operation. Reconcile uncertain provider results before retrying.

Refunds and partial refunds

A refund can be full or partial. The eligible amount depends on the confirmed paid amount, previous refunds, and processor rules. A partially captured payment can have eligible refundable funds, but it must not be treated as if the full authorization had been captured.

A refund can complete synchronously or use an intermediate payment state:

• refunding indicates that the refund intended to complete the eligible balance is in progress.
• partial_refunding indicates that a partial refund is in progress.
• partial_refunded confirms partial refund progress.
• refunded confirms completion of the refundable balance in this lifecycle.

Full refunds can also begin directly from processed, captured, or an eligible partial_captured state. Synchronous refunds can move directly to partial_refunded or refunded without an observed intermediate state.

Multiple partial refund execution modes

As with captures, use provider-native multiple partial refunds when the provider supports the required flow. DEUNA aggregation addresses unsupported native flows and applicable asynchronous refund limitations. Native-first is the integration policy; verify the configured MPR mode before assuming how a connection submits refunds.

See MPR — Multiple Partial Refunds for enablement, processing windows, and aggregation behavior. Capture and refund aggregation have separate settings; do not apply final_capture to a refund.

Full refund or refund of the remaining balance

The orange entry box is a flow marker, not a payment status. Eligible starting states are processed, captured, partial_captured, or partial_refunded, subject to confirmed amounts and provider rules.

flowchart TB
    entry_paid["Eligible paid payment"]
    sync(["refunded<br/>TERMINAL"])
    work["refunding"]
    ok(["refunded<br/>TERMINAL"])
    entry_paid -->|"Immediate refund"| sync
    entry_paid -->|"Refund pending"| work
    work -->|"Confirmed"| ok
    classDef context fill:#FFF1E8,stroke:#FF5500,color:#172B4D,stroke-width:1px;
    class entry_paid context;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    class sync,ok terminal;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;

Partial refund

Use the same eligible starting states. To request another partial refund, follow this panel again with the remaining refundable balance. The payment remains the same lifecycle; there is no backward arrow to trace.

flowchart TB
    entry_paid["Eligible paid payment"]
    sync["partial_refunded"]
    work["partial_refunding"]
    part["partial_refunded"]
    full(["refunded<br/>TERMINAL"])
    entry_paid -->|"Immediate partial<br/>refund"| sync
    entry_paid -->|"Partial refund pending"| work
    work -->|"Partial amount<br/>confirmed"| part
    work -->|"Refundable balance<br/>exhausted"| full
    classDef context fill:#FFF1E8,stroke:#FF5500,color:#172B4D,stroke-width:1px;
    class entry_paid context;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    class sync,part success;
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    class work transient;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    class full terminal;

A completed partial refund can be the final intended business outcome. No further refund is required solely because an eligible balance remains.

Failed refunds preserve prior financial history

A refund-operation denial is not automatically a payment denial. Check previously confirmed purchases, captures, and refunds.

Recovery from a full refund in progress

flowchart TD
    r["refunding"]
    p["processed"]
    c["captured"]
    pr["partial_refunded"]
    r -->|"Confirmed purchase<br/>remains"| p
    r -->|"Confirmed capture<br/>remains"| c
    r -->|"Earlier partial refund<br/>remains"| pr
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class r transient;
    class p,c,pr success;

Recovery from a partial refund in progress

flowchart TD
    r["partial_refunding"]
    p["processed"]
    c["captured"]
    pc["partial_captured"]
    pr["partial_refunded"]
    r -->|"Purchase remains"| p
    r -->|"Full capture remains"| c
    r -->|"Partial capture<br/>remains"| pc
    r -->|"Earlier refund remains"| pr
    classDef transient fill:#FFF4CC,stroke:#967000,color:#172B4D,stroke-width:2px;
    classDef success fill:#E6F0FF,stroke:#235B9A,color:#172B4D,stroke-width:2px;
    classDef terminal fill:#DFF3E8,stroke:#137447,color:#172B4D,stroke-width:2px;
    classDef exception fill:#FFF0E0,stroke:#C55A11,color:#713B12,stroke-width:2px;
    class r transient;
    class p,c,pc,pr success;

Preserve the original financial history after a failed refund. Determine refund completion from confirmed amounts and the reported payment status. Reconcile a result that conflicts with those amounts before retrying.

If the payment update itself reports denied, treat it as terminal and stop fulfillment. Confirm a refund-operation failure before another refund; a missing response is not proof of failure.

Settlement-file processing

For applicable processors that use settlement files, a refund requested before settlement-file submission can lead directly from processing or capturing to a refunded state. After submission, the flow can use refunding or partial_refunding before confirmation.

This behavior is specific to the applicable settlement-file integration. It is not a general permission to refund every payment that is still processing.

Denials, expiration, and cancellations

Denied and expired outcomes

denied is a terminal unsuccessful outcome in this guide. Stop fulfillment and retain the reported reason and financial history. No recovery path is documented for this status.

expired is also terminal. DEUNA can set it through configured payment deadlines from pending or processing. For 3DS, pending_3ds → expired follows the issuer's authentication time limits, not the DEUNA APM payment-deadline setting. Use the actual payment field; a local timer does not establish expiration.

Uncertain responses

An HTTP timeout, a lost response, or a late webhook does not prove denial or expiration. Reconcile the payment and affected operation before sending another request that can move funds. Follow DEUNA's idempotent request guidance; a new attempt and a retry of an uncertain request are different situations.

Handling payment updates

Configure and interpret notifications

See DEUNA Webhooks for webhook setup and notification guidance. This page focuses on the payment status inside the applicable payload.

For Purchase V2, the asynchronous refund guide documents order.webhook_urls.notify_order as the notification configuration. Read payment.data.status (order.payment.data.status when wrapped) in the applicable update, and correlate capture or refund details with their operation identifiers.

For each update:

1. Verify the notification using the configured DEUNA webhook-verification method.
2. Identify the payment and any related operation before updating local records.
3. Retain the reported amounts, currency, operation identifiers, and provider references that the payload supplies.
4. Distinguish pending operation amounts from confirmed financial amounts.
5. Apply the payment transition and the merchant's fulfillment or refund policy.
6. Reconcile missing or conflicting outcomes through the supported payment-retrieval flow.

Handle repeated notifications without applying the same financial result twice. Do not identify duplicates by status alone, or assume that a later-arriving message must describe a later operation. Do not invent an event sequence or version field that the applicable payload does not provide.

Use the status with financial context