Skip to main content
All systems operationalChangelogv1
Log in
Payments · Workflows and statuses

Card Payment Workflow

Follow card purchase, authorization, 3DS, review, capture, void, and refund states without mixing authentication with payment success.

On this page

Card payments use either a single-step purchase or a two-step authorization-and-capture model. Read the current value from payment.data.status; if the payment is inside an order response, read order.payment.data.status.

Use this page for the card-specific path. For every status definition and allowed direct transition, see Payment workflow and statuses.

Purchase and authorization#

The configured processor connection determines whether DEUNA performs a purchase or an authorization. A 3DS challenge can precede either operation.

Flow diagram
3DS requiredPurchaseAuthorizationAuthenticated purchaseAuthenticatedauthorizationTime limit reachedConfirmedConfirmedDeclinedDeclined1pendingPayment created2pending_3dsCustomerauthentication3processingPurchase in progress4authorizingAuthorization inprogress5processedFunds collected6authorizedFunds reserved7deniedAttempt unsuccessful8expiredCompletion windowclosed
Review or pendingResult or outcomeException or stop
StateMeaningMerchant action
pendingThe card payment exists, but routing, authentication, or processing may not have started.Follow next_action when present and keep fulfillment blocked.
pending_3dsIssuer authentication is incomplete.Complete the challenge and then evaluate the new payment status.
processingA purchase request is in progress.Wait for processed or another authoritative outcome.
authorizingA two-step authorization is in progress.Wait for authorized or another authoritative outcome.
processedA purchase completed and funds were collected.Apply the fulfillment policy; the payment can still be refunded.
authorizedFunds were reserved, not collected.Capture or void within the limits of the processor connection.

3DS and OTP

Authentication success only allows the card flow to continue. It does not prove that a purchase or authorization succeeded. After the challenge, wait for processed, authorized, or another reported payment status.

Some processor adapters use pending_otp internally. Current payment processing normalizes that result to public pending and supplies the required next-action metadata. If an older report or search filter contains pending_otp, treat it as awaiting customer action—not as payment success.

Risk review and retries#

manual_review holds fulfillment until a risk decision produces a new payment status. An approved review can continue to processed or captured; a rejected review can produce denied. See Fraud workflow and statuses for the separate fraud fields and decisions.

denied describes the unsuccessful attempt, but the Payments state machine can route or retry the same payment into pending, pending_3ds, processing, or authorizing. Do not fulfill a denied attempt, and do not model denied as a terminal payment status.

Capture an authorization#

Capture converts reserved funds into collected funds. The processor, remaining authorized amount, time limits, and merchant configuration determine which capture operations are eligible.

Flow diagram
Full capturePartial captureConfirmedFailedConfirmedComplete remainingamountCapture more1authorizedFunds reserved2capturingFull capture inprogress3partial_capturingPartial capture inprogress4capturedFunds collected5partial_capturedPartially collected6deniedCapture attempt failed
Result or outcomeReview or pendingException or stop

The state machine can also receive captured or partial_captured directly without exposing the matching “-ing” status. Notifications are authoritative snapshots, not a guaranteed event-by-event sequence.

For partial-capture modes, supported concurrency, time limits, and final_capture, see MPC — Multiple Partial Captures.

Void an authorization#

Void releases reserved funds. It is different from a refund, which returns funds that were already collected.

Flow diagram
VoidConfirmedFailed1authorizedFunds reserved2voidingRelease in progress3voidedTERMINAL4authorizedRelease failed
Result or outcomeReview or pending

The successful Void API returns HTTP 204 No Content. When the processor completes asynchronously, use the later payment state as the result.

Refund collected funds#

A successful purchase, full capture, or partial capture can be refunded when the connection and remaining refundable amount allow it.

Flow diagram
Full refundPartial refundRefund captured amountConfirmedConfirmedRefund remainingbalance1processed orcapturedCollected funds2partial_capturedPartially collected3refundingFull or remainingbalance4partial_refunding5partial_refunded6refundedTERMINAL
Result or outcomeReview or pending

A failed refund can restore processed, captured, or partial_captured. Preserve the successful payment and failed refund attempt separately. See MPR — Multiple Partial Refunds for native and DEUNA-aggregated modes, time limits, concurrency, and remaining-balance behavior.

Integration checklist#

  1. Keep fulfillment blocked for pending, pending_3ds, processing, authorizing, and manual_review.
  2. Treat authentication and request acceptance as intermediate evidence, not financial confirmation.
  3. Store confirmed amounts and operation identifiers with every status update.
  4. Retrieve the authoritative payment after a timeout or delayed provider response.
  5. Use the validated transition reference when handling retries or reconciliation paths not shown in the normal flow.