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.

%%{init: {'flowchart': {'curve': 'linear'}, 'theme': 'dark'}}%%
graph TD
    start(Transaction Initiated) --> check_init{Initialization Required?}

    check_init -- **No (Sync Auth)** --> authorized_sync(authorized)
    
    check_init -- **Yes (Async Auth)** --> login_step[3DSecure or E-Wallet Login]
    
    login_step --> authorized_sync

    authorized_sync --> decision_point{Intent:<br> Capture or Cancel?}
    
    decision_point -- Intent: Capture --> capture[Capture by Merchant]
    decision_point -- Intent: Cancel --> rejected_cancelled(rejected - Cancelled)

    %% Capture Paths branching from Capture node
    
    capture --> approved_path{Success <br>or<br> No Validation}
    capture --> pending_path{Validation Required}
    capture --> rejected_path{Rejection <br>or<br> No Validation}
    
    approved_path -- Final Status --> approved_status(approved)
    rejected_path -- Final Status --> rejected_status(rejected - Failed)

    pending_path --> pending_val(pending)
    pending_path --> pending_rej(pending)
    
    pending_val -- Successful Validation<br> by Acquirer --> approved_status
    pending_rej -- Failed Validation<br> by Acquirer --> rejected_status


    %% Final Status Consolidation
    approved_status --> final_end(Transaction Ended)
    rejected_status --> final_end
    rejected_cancelled --> final_end

---

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

%%{init: {'flowchart': {'curve': 'linear'}, 'theme': 'dark'}}%%
graph TD
    start(Sale Transaction Initiated) --> initial_split{Input Type?}
    
    %% SYNC INPUT PATHS (Instant or simple validation)
    initial_split -- Synchronous Input --> sync_paths
    subgraph sync_paths [Synchronous Sale Flows]
        sync_paths_start(Start Sync)
        
        sync_paths_start -- Rejected (Direct) --> rejected_direct(rejected) 
        sync_paths_start -- Success (Direct) --> approved_direct(approved)

        sync_paths_start -- Success (Validation Req) --> initialized_sync_val(initialized)
        initialized_sync_val -- Validation Success --> approved_sync_val(approved)

        sync_paths_start -- Rejected (Validation Req) --> initialized_sync_rej(initialized)
        initialized_sync_rej -- Validation Failed --> rejected_sync_val(rejected)
    end
    
    %% ASYNC INPUT PATHS (Requires 3DS/E-Wallet)
    initial_split -- Asynchronous Input --> async_paths
    subgraph async_paths [Asynchronous Sale Flows]
        async_paths_start(Start Async) --> login_step[3DSecure or E-Wallet Login]
        login_step --> processing_start{Processing Start}
        
        processing_start -- Success (No Validation) --> approved_async(approved)
        processing_start -- Rejection (Direct/Failed 3DS) --> rejected_async(rejected)
        
        processing_start -- Success + Validation Req --> pending_val(pending)
        pending_val -- Validation Approved --> approved_async
        
        processing_start -- Rejected + Validation Req --> pending_rej(pending)
        pending_rej -- Validation Rejected --> rejected_async
    end

    approved_direct --> Final_End(Transaction Ended)
    rejected_direct --> Final_End
    approved_sync_val --> Final_End
    rejected_sync_val --> Final_End
    approved_async --> Final_End
    rejected_async --> Final_End

---

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).

%%{init: {'flowchart': {'curve': 'linear'}, 'theme': 'dark'}}%%
graph TD
    start(Payout Transaction Initiated) --> initial_split{Input Type?}
    
    %% SYNC INPUT PATHS (Instant or simple validation)
    initial_split -- Synchronous Input --> sync_paths
    subgraph sync_paths [Synchronous Payout Flows]
        sync_paths_start(Start Sync)
        
        sync_paths_start -- Rejected (Direct) --> rejected_direct(rejected) 
        sync_paths_start -- Success (Direct) --> approved_direct(approved)

        sync_paths_start -- Success (Validation Req) --> initialized_sync_val(initialized)
        initialized_sync_val -- Validation Success --> approved_sync_val(approved)

        sync_paths_start -- Rejected (Validation Req) --> initialized_sync_rej(initialized)
        initialized_sync_rej -- Validation Failed --> rejected_sync_val(rejected)
    end
    
    %% ASYNC INPUT PATHS (Requires EW Login)
    initial_split -- Asynchronous Input --> async_paths
    subgraph async_paths [Asynchronous Payout Flows]
        async_paths_start(Start Async) --> login_step[E-Wallet Login]
        login_step --> processing_start{Processing Start}
        
        processing_start -- Success (No Validation) --> approved_async(approved)
        processing_start -- Rejection (Direct/Failed Login) --> rejected_async(rejected)
        
        processing_start -- Success + Validation Req --> pending_val(pending)
        pending_val -- Validation Approved --> approved_async
        
        processing_start -- Rejected + Validation Req --> pending_rej(pending)
        pending_rej -- Validation Rejected --> rejected_async
    end

    approved_direct --> Final_End(Payout Concluded)
    rejected_direct --> Final_End
    approved_sync_val --> Final_End
    rejected_sync_val --> Final_End
    approved_async --> Final_End
    rejected_async --> Final_End

---

Refund

%%{init: {'flowchart': {'curve': 'linear'}, 'theme': 'dark'}}%%
graph TD
    start(Refund Transaction Initiated) --> initial_split{Input Type?}
    
    %% SYNC INPUT PATHS (Instant or simple validation)
    initial_split -- Synchronous Input --> sync_paths
    subgraph sync_paths [Synchronous Refund Flows]
        sync_paths_start(Start Sync)
        
        sync_paths_start -- Rejected (Direct) --> rejected_direct(rejected) 
        sync_paths_start -- Success (Direct) --> approved_direct(approved)

        sync_paths_start -- Success (Validation Req) --> initialized_sync_val(initialized)
        initialized_sync_val -- Validation Success --> approved_sync_val(approved)

        sync_paths_start -- Rejected (Validation Req) --> initialized_sync_rej(initialized)
        initialized_sync_rej -- Validation Failed --> rejected_sync_val(rejected)
    end
    
    %% ASYNC INPUT PATHS (Requires EW Login)
    initial_split -- Asynchronous Input --> async_paths
    subgraph async_paths [Asynchronous Refund Flows]
        async_paths_start(Start Async) --> login_step[E-Wallet Login]
        login_step --> processing_start{Processing Start}
        
        processing_start -- Success (No Validation) --> approved_async(approved)
        processing_start -- Rejection (Direct/Failed Login) --> rejected_async(rejected)
        
        processing_start -- Success + Validation Req --> pending_val(pending)
        pending_val -- Validation Approved --> approved_async
        
        processing_start -- Rejected + Validation Req --> pending_rej(pending)
        pending_rej -- Validation Rejected --> rejected_async
    end

    approved_direct --> Final_End(Refund Concluded)
    rejected_direct --> Final_End
    approved_sync_val --> Final_End
    rejected_sync_val --> Final_End
    approved_async --> Final_End
    rejected_async --> Final_End

Withdrawal

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

%%{init: {'flowchart': {'curve': 'linear'}, 'theme': 'dark'}}%%
graph TD
    start(WD Request Received) --> initial_check{Customer Verification Required?}

    %% INITIALIZATION/REQUESTED PATH
    initial_check -- Awaiting Customer Action --> initialized(initialized)
    initial_check -- Ready for Merchant --> requested(requested)
    initialized --> requested
    
    %% MERCHANT ACTION POINT
    requested --> merchant_action{Merchant Action:<br> Approve or Cancel?}
    
    merchant_action -- Cancelled by Merchant/Customer --> cancelled(cancelled)
    merchant_action -- Approval --> payout_split{Trigger Payout or Refund}
    merchant_action -- Error Occurs --> error_status(error)
    
    %% PROCESSING PATH (SPLIT LOGIC)
    payout_split -- First Attempt Success --> split_partial(split_partial)
    payout_split -- Full Processing Success --> approved_final(approved)
    
    payout_split -- Error During Payout --> error_status
    
    %% SPLIT/PARTIAL PATHS
    split_partial --> partial_status(partial)
    partial_status -- Subsequent Payout/Refund --> split_partial
    partial_status -- Final Payout/Refund --> split_final(split)
    
    approved_final --> Final_End(WD Balance Fulfilled)
    split_final --> Final_End
    cancelled --> Final_End
    error_status --> Final_End