Processing Transaction Flow

• TRANSACTION STATUSES
• AUTHORIZATION
• SALE
• PAYOUT
• REFUND
• WITHDRAWAL REQUEST

Each transaction type follows a specific flow due to processing characteristics. Below you’ll find flow diagrams for each transaction type, including the sequence of status changes and indications where interaction is required.

Transaction Statuses

The statuses listed below apply to standard transactions. Withdrawal Request has a dedicated flow described in its own section.

The following transaction_status values may be encountered throughout the transaction lifecycle.

Payment

• pending – Waiting for updates from the payment service provider (PSP).
• approved – Payment was approved and funds have been sent.
  • At this point, any related withdrawal request (if present) transitions to either payment or split. This change is not reflected in notifications but can be retrieved using find-transaction with the withdrawal request tid.
• rejected – Payment was rejected by the PSP.
• error – An unexpected error occurred during processing.
  • At the same time, related withdrawal request falls under verification - sometimes a payment processing error indicates the communication error, while the funds are sent successfully. The withdrawal request is marked for verification in order for the merchant to make sure that the funds have not been sent.
• canceled – Payment was canceled, typically in the following scenarios:
  • The customer initiates a deposit but cancels it while on the PSP redirect page.
  • Cancellation occurs during 3DSecure flow or via APM interfaces (e.g. Neteller, Skrill) that provide a "Cancel" button.
  • If supported by the PSP integration, a cancel notification or error is sent back. Our system maps this to the canceled status.
  • Integration Notes: Sometimes integrations are updated to better reflect the PSP cancellation in our system to ensure status consistency across platforms.

Withdrawal

• initialized – Waiting for the customer to finalize withdrawal submission (e.g., additional information being collected).
• requested – Withdrawal request submitted, awaiting merchant approval.
• partial_payout – Part of the withdrawal request amount has been processed (via payout or refund).
• split – Full withdrawal request amount has been processed (via payouts or refunds).
• error – An unexpected error occurred during the withdrawal submission.

Withdrawal-to-Payout (Combined)

• initialized – Awaiting customer to finalize the e-wallet or 3DSecure verification.
• pending – Waiting for updates from the PSP.
• approved – Transaction approved and funds sent.
• rejected – Transaction rejected by the PSP.
• error – An unexpected error occurred during processing.
• requested – Withdrawal request submitted for merchant approval.
• canceled – Canceled via:
  • Manage Withdrawal Request API – Action set to cancellation.
  • Atlas Platform – Manual cancellation by the merchant via the dashboard.

Payout

• pending – Waiting for updates from the PSP.
• approved – Payout approved and funds sent.
  • Related payout request (if any) becomes partial_payout or split. This change is not reflected in notifications but can be retrieved via find-transaction with the withdrawal tid.
• rejected – Payout rejected by the PSP.
• error – An error occurred during processing.
  • At the same time, related withdrawal request falls under verification - sometimes a payout processing error indicates the communication error, while the funds are sent successfully. The withdrawal request is marked for verification in order for the merchant to make sure that the funds have not been sent.

Refund

• pending – Waiting for updates from the PSP.
• approved – Refund approved and funds sent.
  • Related withdrawal request (if applicable) updates to partial_payout or split, which can be retrieved via find-transaction find-transaction with the withdrawal tid.
• rejected – Refund rejected by the PSP.
• error – Unexpected error during processing.
  • At the same time, related withdrawal request falls under verification - sometimes a refund processing error indicates the communication error, while the funds are sent successfully. The withdrawal request is marked for verification in order for the merchant to make sure that the funds have not been sent.

Note: If you're using the combined Withdrawal-to-Payout flow, where payouts are processed under the same tid as the withdrawal, and you prefer having separate identifiers for withdrawal, payout, and refund — please contact support to enable the Create new payout transaction upon WD complete setting.

Authorization

The authorization transaction refers to a "safe" or "complex" payment flow. In this model, the amount is locked on the customer's card or e-wallet account until confirmed by the merchant, usually following customer verification or item stock confirmation.

Note: Authorization transactions may involve 3DSecure verification.

Successful synchronous capture with additional validation by acquirer (synchronous auth, asynchronous processing)

authorized → [capture by merchant] → [processing by acquirer] → approved

Successful synchronous capture (synchronous auth, synchronous processing)

authorized → [capture by merchant] → [processing by acquirer] → approved

Successful async capture with additional validation by acquirer (asynchronous auth, asynchronous processing)

initialized → [3DSecure or EW login] → authorized → [capture by merchant] → pending → [validation by acquirer] → [processing by acquirer] → approved

Successful async capture (asynchronous auth, synchronous processing)

initialized → [3DSecure or EW login] → authorized → [capture by merchant] → [processing by acquirer] → approved

Rejected synchronous capture with additional validation by acquirer (synchronous auth, asynchronous processing)

authorized → [capture by merchant] → pending → [validation by acquirer] → [processing by acquirer] → rejected

Rejected synchronous capture (synchronous auth, synchronous processing)

authorized → [capture by merchant] → [processing by acquirer] → rejected

Rejected async capture with additional validation by acquirer (asynchronous auth, asynchronous processing)

initialized → [3DSecure or EW login] → authorized → [capture by merchant] → pending → [validation by acquirer] → [processing by acquirer] → rejected

Rejected async capture (asynchronous auth, synchronous processing)

initialized → [3DSecure or EW login] → authorized → [capture by merchant] → [processing by acquirer] → rejected

Cancelled synchronous authorization (synchronous processing)

authorized → [cancellation by merchant] → rejected

Cancelled async authorization (asynchronous processing)

initialized → [3DSecure or EW login] → authorized → [cancellation by merchant] → rejected

Sale

The sale transaction type is intended for instant processing. The payment details will be instantly sent to acquirer for the following processing status -or- 3DSecure verification and further processing status

Successful synchronous sale with additional validation by acquirer (synchronous input, asynchronous processing)

initialized → [validation by acquirer] → approved

Successful synchronous sale (synchronous input, synchronous processing)

approved

Successful async sale with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [3DSecure or EW login] → pending → [validation by acquirer] → [processing by acquirer] → approved

Successful async sale (asynchronous input, synchronous processing)

initialized → [3DSecure or EW login] → [processing by acquirer] → approved

Rejected synchronous sale with additional validation by acquirer (synchronous input, synchronous processing)

initialized → [validation by acquirer] → rejected

Rejected synchronous sale (synchronous input)

rejected

Rejected async sale with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [3DSecure or EW login] → pending → [validation by acquirer] → [processing by acquirer] → rejected

Rejected async sale or failed 3DS challenge (asynchronous input, synchronous processing)

initialized → [3DSecure or EW login] → [processing by acquirer] → rejected

Payout

The payout transaction, or CFT (fund transfer to customer). With payout transaction the merchant can send any amount to any payment details (credit card, bank account or e-wallet).

Successful synchronous payout with additional validation by acquirer (synchronous input, asynchronous processing)

initialized → [validation by acquirer] → approved

Successful synchronous payout (synchronous input, synchronous processing)

approved

Successful async payout with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [EW login] → pending → [validation by acquirer] → [processing by acquirer] → approved

Successful async payout (asynchronous input, synchronous processing)

initialized → [EW login] → [processing by acquirer] → approved

Rejected synchronous payout with additional validation by acquirer (synchronous input, synchronous processing)

initialized → [validation by acquirer] → rejected

Rejected synchronous payout (synchronous input)

rejected

Rejected async payout with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [EW login] → pending → [validation by acquirer] → [processing by acquirer] → rejected

Rejected async payout (asynchronous input, synchronous processing)

initialized → [EW login] → [processing by acquirer] → rejected

Refund

The refund transaction is an extension (continuation) to authorization or sale. Refund would use the original payment in order to reverse the transaction in a way that the same customer's card or e-wallet will receive funds from the same merchant's bank account.

Successful synchronous refund with additional validation by acquirer (synchronous input, asynchronous processing)

initialized → [validation by acquirer] → approved

Successful synchronous refund (synchronous input, synchronous processing)

approved

Successful async refund with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [EW login] → pending → [validation by acquirer] → [processing by acquirer] → approved

Successful async refund (asynchronous input, synchronous processing)

initialized → [EW login] → [processing by acquirer] → approved

Rejected synchronous refund with additional validation by acquirer (synchronous input, synchronous processing)

initialized → [validation by acquirer] → rejected

Rejected synchronous refund (synchronous input)

rejected

Rejected async refund with additional validation by acquirer (asynchronous input, asynchronous processing)

initialized → [EW login] → pending → [validation by acquirer] → [processing by acquirer] → rejected

Rejected async refund (asynchronous input, synchronous processing)

initialized → [EW login] → [processing by acquirer] → rejected

Withdrawal Request

A withdrawal request is not a transaction itself, but a trigger for subsequent payout or refund transactions.

The following transaction_status values may occur during its lifecycle:

• initialized – Awaiting customer to complete e-wallet login or 3DSecure.
• requested – Submitted and awaiting merchant processing.
• partial – Partial amount processed (status partial in CRM, Partial Payout in Admin).
• approved – Full amount processed, applicable to combined Withdrawal-to-Payout flows.
• cancelled – Canceled by the merchant or customer (refer to edited_by).
• error – An error occurred during processing.
• split_partial – This status means that a WD request has been processed partially, the status will be indicated after the first attempt and appears only in response to find-transaction API call being requested for WD request tid.
• split – Final withdrawal request status after the requested balance has been fully withdrawn, either in parts or with a single transfer. Appears only in response to find-transaction API call being requested for WD request tid.