ANED
Pay
Platform
ANED Suite
What ANED Pay removes is the month-end reconstruction — and the integration project that normally stands between you and avoiding it. No developer, no gateway documentation, no callback URLs to host. You connect the accounts you already have, and what moves through them is recorded, matched to the customer or supplier, and posted to your ledger as it happens.
A finance manager keys in their own till, paybill or bank credentials, presses Test, and is collecting. Each provider asks for its fields using the exact names that provider's own portal uses, so the values can be copied across without interpretation. Credentials are encrypted at rest, are never returned by the API, and are verified against the provider before a connection can go live. Every connection declares what it can actually do — collect, prompt, pay out, read balance — so you know before you use it, not after.
Your paybill and till are polled continuously, so a payment appears whether or not anyone was expecting it — each one recorded, then acknowledged back to the gateway so nothing is counted twice and nothing is missed. Where you want to ask for a payment rather than wait for it, a prompt (M-Pesa Express / STK Push) can be raised against a specific order and confirmed by result code, capturing the receipt onto that order. Bank collections run the same poll-and-acknowledge cycle; I&M Bank is connected today.
The outbound half of the ledger is populated by paying through ANED Pay: supplier payments, refunds and payroll or beneficiary runs, as single payments or a batch approved as a whole and executed row by row. Each one lands in the same ledger as the money coming in, so both directions reconcile together. Nothing moves without explicit approval, every payment carries an idempotency key enforced in the database, and none is silently retried once sent — an unresolved payment is queried rather than repeated, because a retry could pay someone twice. Payments execute over M-Pesa B2C today. Debits your team makes elsewhere — straight from the banking app, say — are not pulled in yet: that needs a bank statement feed, which is catalogued but not built.
Incoming payments are resolved to the customer behind them by account number, derived from your own customer numbers. Mis-keyed references — and payers will mis-key them — are visible as a list of what people actually typed, correctable from the payment row itself. Resolution can be re-run across every unmatched payment at any time; already-matched payments are left alone.
Every payment in and out becomes a journal entry in your accounting system, with the ANED Pay fee expensed alongside inbound entries so the books reflect what you actually netted. ANED Pay pushes through the accounting system's API using credentials you supply — it never reaches into your database. Posting is at-least-once with idempotency, so a network failure cannot lose an entry and a retry cannot post it twice. ANED ERP is connected today; QuickBooks Online, Sage Business Cloud, Odoo and Xero sit behind the same interface and are not yet built.
ANED Pay is a product, not a plug-in: it owns its own data, API and console, and your systems embed it at arm's length in three ways — a REST API authenticated by a per-integration host key, HMAC-signed webhooks delivered at least once with replay, and React components or the hosted operator console. Python and TypeScript SDKs are provided. Nothing in ANED Pay imports one of your models, which is why the same product embeds into ANED ERP, a partner's platform, or software ANED did not write.
Where something is connected and running today, the description says what it does. Where it is catalogued with the interface in place but not yet built, the description says that instead — nothing here is implied to work when it does not.
One record of every payment in and out, whichever account it moved through. Payer matching, reconciliation state, and the settlement journal behind each entry.
Your own tills, paybills and bank accounts, keyed in by your finance team. Credentials encrypted at rest, write-only over the API, and verified against the provider before going live.
Money in — paybill and till collections, payment prompts against a specific order, and bank transfers, each recorded and acknowledged so nothing is counted twice.
Money out — suppliers, refunds, payroll and beneficiary runs, single or as a batch, each landing in the same ledger as the money coming in. Explicit approval, database-enforced idempotency, and never a silent retry on a payment already sent.
Paybill and till collections (C2B), polled and acknowledged in a two-phase handshake, plus B2C payouts and a balance check before a batch goes out.
Prompt a customer to pay against a specific sales order, then confirm by result code, capturing the M-Pesa receipt onto the order itself.
Bank transfer collections on the same poll-and-acknowledge cycle as M-Pesa, so bank receipts and mobile money land in one ledger.
Airtel Money, MTN MoMo, Orange Money, Wave, Equity, KCB, Co-operative, NCBA, cards and Flutterwave are catalogued with the fields each one needs — the connectors are not built yet, and nor is bank statement retrieval, so debits made outside ANED Pay are not read in.
Each transaction posted as a journal entry through the accounting system’s own API, with the ANED Pay fee expensed alongside inbound entries. At-least-once, with idempotency.
Declared behind the same accounting interface as ANED ERP, so the transaction side needs no change when they land. Not yet implemented.
Payments resolved to customers by an account number derived from your own customer numbers, with mis-keyed references listed and correctable, and resolution re-runnable at will.
Fees accrue per transaction and are invoiced in arrears, itemised, so any invoice line traces back to the payment behind it.
A separate key per integrating system, hashed at rest, with capability flags and rotation, so a compromised integration is revoked without touching the others.
HMAC-SHA256 over the raw body, delivered at least once with exponential backoff, auto-disabled after repeated failure, and replayable by an operator.
A Python client for Django and other server-side hosts, and a typed TypeScript client with embeddable React components for your own front end.
Money in, unmatched, posted and live channels at a glance, plus connections, payments, payouts, reconciliation, accounting and integrations screens.
Your till, your paybill, your bank account. Set up by the people who run your finances, in minutes — and what comes in and what goes out lands in the ledger, reconciled, without anyone typing it in.