Processing Transaction Flow

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

Each transaction type has it's own flow due to processing specifics. Below you can find the processing flow illustration per each type, including the sequence of status changes and indication of interaction required at certain steps.

Transaction Statuses

Below statuses apply to regular transactions. Withdrawal request has it's own flow that is described in it's own section.

The following transaction_status values may appear through the transaction lifecycle.

Payment

• pending - waiting for updates from payment service provider
• approved - payment transaction has been approved, funds sent
  • At the same time, withdrawal request related to this payment (if any) becomes either payment or split, which is not reflected within the notifications but can be retrieved by using find-transaction for tid of withdrawal request.
• rejected - payment transaction has been rejected by the payment service provider
• error - unexpected error has occurred during the 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 transaction is marked as canceled when:
  • A deposit transaction is marked as "Canceled" if the customer initiates a deposit but decides to cancel the transaction while being redirected to the payment service provider (PSP).
  • The cancellation can occur at various stages, such as during the 3D Secure verification process or on the Alternative Payment Method (APM) interface like Neteller or Skrill. These platforms typically have a cancel button that the customer can press to stop the transaction process.
  • If the PSP integration supports this feature, it sends back a notification or an error description indicating that the transaction was canceled by the customer. Our system then updates the transaction status to "Canceled" based on the information received from the PSP.
  • Integration Updates: Sometimes we update the integrations to clearly map the cancellation on the PSP side to the "Canceled" status on our side. This ensures that the status reflects accurately across both platforms

Withdrawal

• initialized - waiting for customer to finalize the withdrawal request submission (additional info being collected)
• requested - customer has submitted a withdrawal request for merchant approval
• partial_payout - withdrawal request is partially managed, there is related payout(s) or refunds for partial amount of present withdrawal request
• split - withdrawal request is fully managed, there is related payout(s) or refunds equivalent to the amount of present withdrawal request
• error - unexpected error has occurred during the withdrawal request submission

Withdrawal -to- Payout (combined)

• initialized - waiting for customer to finalize the e-wallet login or 3D Secure verification
• pending - waiting for updates from payment service provider
• approved - transaction has been approved, funds sent
• rejected - transaction has been rejected by the payment service provider
• error - unexpected error has occurred during the processing
• requested - customer has submitted a withdrawal request for merchant approval
• canceled - Merchants can cancel a withdrawal request through two primary methods:
  • Manage Withdrawal Request API: Using the API call for managing withdrawal requests with "cancellation" selected as the action.
  • Atlas Platform: Merchants can access Atlas, find the specific withdrawal transaction, and manually cancel it.

Payout

• pending - waiting for updates from payment service provider
• approved - payout transaction has been approved, funds sent
  • At the same time, withdrawal request related to this payout (if any) becomes either partial_payout or split, which is not reflected within the notifications but can be retrieved by using find-transaction for tid of withdrawal request.
• rejected - payout transaction has been rejected by the payment service provider
• error - unexpected error has occurred during the 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 payment service provider
• approved - refund transaction has been approved, funds sent
  • At the same time, withdrawal request related to this refund (if any) becomes either partial_payout or split, which is not reflected within the notifications but can be retrieved by using find-transaction for tid of withdrawal request.
• rejected - refund transaction has been rejected by the payment service provider
• error - unexpected error has occurred during the 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.

Please note: in case if you have the Withdrawal -to- Payout combined flow, having the withdrawal requests converted into payouts under the same tid, and - if you would like to switch to distinct indication of withdrawal requests, payouts and refunds, please reach out to our support and request to have the Create new payout transaction upon WD complete setting enabled.

Authorization

The authorization transaction can be also referred to as "safe" or "complex" payment flow, where the amount is locked on the customer's card or e-wallet account until the confirmation by the merchant, usually upon the customer verification or confirmation of items allocated in stock.

Please note that the authorization transactions may undergo the 3DSecure challenge.

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

Withdrawal request is not a real transaction, but the origin for it's following payout and refund transactions.

The following transaction_status values may appear through the lifecycle of a withdrawal request:

• initialized - waiting for customer to finalize the e-wallet login or 3D Secure verification.
• requested - withdrawal request has been submitted, waiting for the merchant to do the processing.
• partial - part of the withdrawal request amount has been processed with following payouts and refunds (status: partial is sent to CRM in the notification, status: Partial Payout is displayed in Admin).
• approved - full withdrawal request amount has been processed with following payouts and refunds, applicable to combined Withdrawal -to- Payout flow.
• cancelled - transaction has been cancelled by the merchant or customer (refer to edited_by).
• error - unexpected error has occurred during the processing.
• split_partial - 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 - the 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.