Flow of Funds

A VAS purchase moves money in two separate legs: the customer pays the merchant through the till's normal payment mechanism, and Eclipse settles the VAS reseller through a wallet-to-wallet transfer. The two legs are linked by the till transaction, but they are not the same movement of funds.

The flow

1. The VAS reseller pre-funds their eSolutions account, represented in Eclipse by a VAS reseller wallet. This wallet is topped up ahead of time and is the source of funds for every VAS purchase the reseller's tills process.
2. A customer requests a VAS product at the till. The request flows from the till through eSocket.POS, to Postilion, to Eclipse.
3. Eclipse settles the purchase between wallets: the VAS reseller's wallet is debited, and the VAS destination wallet (configured per VAS provider — and optionally per reseller — in tenant configuration) is credited for the same amount.
4. The customer pays the merchant through the merchant's standard payment mechanism — cash, or card acquiring routed through iPOS to the merchant's own account. This is a separate settlement from step 3 and does not itself move funds through Eclipse.
5. Once payment is confirmed, the VAS is provisioned — the token, airtime, or bill confirmation is issued through eSolutions and returned to the till over the same path in reverse: eSolutions to Postilion to eSocket.POS, for the till to print or display to the customer.

Commission payments

VAS resellers are typically paid a commission on the VAS volume they sell, under their commercial agreement with EFT Corp. When eSolutions pays out an agreed commission, it is credited back into the same VAS reseller wallet that funds purchases in step 1 — it does not arrive in a separate wallet. This tops the reseller's wallet back up independently of, and in addition to, any manual top-ups the reseller makes.

Reversals

A reversal follows the same path in reverse: if a VAS purchase must be backed out (for example, a PROCURE that the till cannot confirm was successfully completed, or a printer failure after the token was issued), Eclipse reverses the wallet movement from step 3 — crediting the VAS reseller's wallet and debiting the VAS destination wallet — and eSolutions is notified through the same Postilion/eSocket.POS path so it can void or reverse the provisioned VAS where the upstream product allows it.

Reporting and reconciliation

Every wallet movement described above — the per-purchase debit/credit, reversals, and commission credits — is a normal Eclipse wallet transaction, so it is already covered by the standard Eclipse reporting suite. You do not need a bespoke VAS report to reconcile this flow:

• Standard Reports catalogues every report available on an Eclipse tenant, including the full wallet transaction ledger (Report_digital_wallet_transaction_detail) and point-in-time wallet balances (Report_digital_wallet_balance) — filter either by the VAS reseller's wallet ID to reconcile purchases, reversals, and commission credits against eSolutions' own statements.
• These reports are run through the same Reports API used for every other Eclipse report — no separate integration is required for VAS reconciliation.