Funds Flow Overview

1. High-Level Architecture

ArosaPay operates a secured transaction model with defined states and ledger controls. Funds do not move directly from buyer to merchant at checkout.

Each transaction follows this structured lifecycle:

• Payment Initiation
• Funds Secured
• Delivery
• Buyer Approval
• Release to Merchant
• Payout Settlement

This model ensures that funds are isolated throughout the transaction lifecycle. Release occurs only upon buyer confirmation or dispute resolution — never automatically at checkout.

2. Core Accounts in the System

For clarity, funds are tracked across five distinct logical accounts. Each account serves a defined purpose and operates under isolation rules.

Buyer Funding Source

• M-Pesa
• Bank account
• Card
• ArosaPay balance (if applicable)

Secured Transaction Ledger

• Holds funds tied to a specific transaction
• Funds are not accessible to the merchant
• Funds are not treated as platform revenue

Merchant Payable Ledger

• Reflects amounts eligible for payout
• May be subject to reserve rules

Reserve Ledger

• Portion of merchant funds temporarily retained
• Released automatically per tier policy

Platform Fee Ledger

• Records service fees upon transaction completion

3. Standard Transaction Flow

Below is the step-by-step funds movement for a standard transaction with no dispute.

Step 1 — Payment Initiated

Buyer selects ArosaPay at checkout. Funding source is charged or authorised.

• Transaction moves to FUNDS_SECURING
• No funds are yet available to merchant

Step 2 — Funds Captured & Held

Payment confirmation is received from the funding source.

• Ledger entry created: Buyer Funding Source → Secured Transaction Ledger
• Transaction status: FUNDS_SECURED
• Merchant notified that funds are held in the Secured Transaction Ledger
• Funds remain isolated — not released

Step 3 — Delivery

Merchant fulfils the order and marks delivery. Inspection window begins.

• No funds move during this stage

Step 4 — Buyer Approval

Buyer confirms satisfaction with the delivered goods or services.

• Ledger split executed: Secured Transaction Ledger → Merchant Payable Ledger + Platform Fee Ledger
• If reserve applies: Merchant Payable Ledger splits into Available for Payout + Reserve Ledger
• Transaction status: APPROVED

Step 5 — Payout Settlement

On the scheduled payout run:

• Merchant Payable Ledger → Merchant Payout Destination (bank account or M-Pesa)
• Reserve remains in Reserve Ledger until hold period expires

4. Funds Flow Diagram

The diagram below summarises the directional movement of funds and status through the system. ASCII variants for the standard and reserve flows follow.

Buyer Funding Source
       |
       v
Secured Transaction Ledger
       |  (upon buyer approval)
       v
  +----+----+
  |         |
  v         v
Merchant   Platform
Payable    Fee Ledger
Ledger
  |
  v
Merchant Bank / M-Pesa

Platform Fee Ledger records the service fee at the approval stage. The remaining amount flows to the Merchant Payable Ledger.

Secured Transaction Ledger
       |
       v
Merchant Payable Ledger
       |
  +----+----+
  |         |
  v         v
Available  Reserve
Portion    Ledger
             |  (after hold period)
             v
         Available
         for Payout

Reserve release occurs automatically after the defined hold period, provided no active disputes, account restrictions, or negative ledger balances exist.

5. Dispute Flow

If a dispute is opened before buyer approval, the following rules apply:

• Funds remain in the Secured Transaction Ledger
• Release to merchant is paused
• Evidence review begins
• No payout occurs during an active dispute

Resolution Outcomes

A) Buyer Prevails

• Secured Transaction Ledger → Refund to Buyer Funding Source

B) Merchant Prevails

• Secured Transaction Ledger → Merchant Payable Ledger
• Standard payout process applies

6. Non-Delivery / Expiry Flow

If the merchant fails to deliver within the agreed window:

• Buyer may cancel the transaction
• Funds move: Secured Transaction Ledger → Refund to Buyer Funding Source
• No payout is processed
• Transaction status: CANCELLED / EXPIRED

7. Ledger Integrity Controls

All fund movements generate immutable ledger entries. Each entry includes:

• Unique transaction ID
• Timestamp
• Event type
• Actor reference
• Source and destination accounts

Balances are derived from the sum of ledger entries. Ledger entries cannot be manually edited, overwritten, or deleted.

8. Reconciliation

Payment provider confirmations are reconciled against:

• Transaction IDs
• Provider references
• Ledger entries

Payout batches are reconciled before settlement confirmation. Any mismatch triggers exception handling and manual review.

9. Risk & Reserve Logic

For certain merchant tiers, upon buyer approval:

• Secured Funds → Merchant Payable Ledger
• Merchant Payable Ledger splits into: Available Portion + Reserve Portion
• Reserve percentage is determined by merchant tier and risk classification

Reserve Release Conditions

Reserve release occurs automatically after the defined hold period if:

• No active disputes exist
• No account restrictions are in place
• No negative ledger balances exist

10. Operational Safeguards

During system instability or operational incidents:

• Secured funds remain isolated
• Release mechanisms may be paused
• Payout processing may be temporarily suspended
• Ledger integrity is verified before resumption

Funds are not released under uncertain ledger conditions. All resumption actions are audit-logged.

11. What ArosaPay Does Not Do

ArosaPay does not:

• Release funds before buyer approval (unless explicitly defined by policy)
• Use secured funds for operating expenses
• Modify ledger balances manually
• Guarantee merchant performance

Funds flow strictly according to transaction state transitions. There are no discretionary overrides.

12. Summary of Movement Conditions

Funds move only when one of the following conditions is met:

• Payment confirmation is received from the funding source
• Buyer explicitly approves the transaction
• Dispute resolution determines the outcome
• Reserve hold period expires with no blocking conditions

There are no discretionary releases. All fund movements are deterministic and audit-logged.