Income Processing Design

A payment records only its processor. The processor says both where the money landed and how it was paid: card at the desk is the card machine, cash at the desk is the cash box. There is no separate payment-method field on a payment.

Order.paymentMethod is different: it is the buyer’s intent before any payment exists — online, EFT, or pay at the counter — chosen on the registration portal’s payment confirmation screen. The last choice wins and can be changed; it decides only the next screen (a redirect to the provider, or the counter reference). A buyer choosing to pay at the counter does not yet know whether they will pay cash or card. The order carries no processor, because an order can be paid in parts through different processors.

Where one provider offers several instruments — Payfast’s card and instant EFT — it is still one processor, because the instruments share one holding account. The instrument a payment used is a detail of the provider’s statement, recorded on the reconciliation row.

Each processor has a dated fee schedule. A rate applies from its effective date, so a rate change never restates earlier payments.

Each processor states its fee source:

A payment keeps both figures:

A fee service is called once, by the service that records a payment, before the payment is saved:

A provider statement line is matched to a recorded payment by, in order:

Lines with no payment behind them are still used: a payout becomes a transfer; payout fees and adjustments post to bank charges; a receipt line with no recorded payment is a payment EMS missed, and is listed for action.

The estimate posts with the payment. When the actual arrives, only the difference posts, as a further entry. The variance between calculated and actual stays visible as a reconciliation finding. Persisted fees are actuals once known, as Order Line Item Amounts requires; the calculation only fills the gap until then.

A fee is charged per payment. It is apportioned to the order lines the payment settles, in proportion to each line’s amount, rounded to cents, with the remainder on the last line, so the lines sum exactly to the charge. An order covers one organiser’s events only, so apportioning across lines also apportions across events.

A service provider’s charges come from a fee table owned by the service provider, maintained under its tenant administration. Each row is keyed by:

Charges apply only to events whose serviceProvider is set. There is no event-level override yet; one can follow the same pattern later.

For each charge type the most specific row wins, in this order:

Charges with no processor dimension resolve this customer, then the default. A customer row therefore overrides the default for its own charge type only; every other charge type still comes from the default. A customer’s own agreement always outranks a processor-specific default row.

Multiplier. Per-paid-entry and per-timed-participant charges carry a multiplier set on the event, per charge type, defaulting to 1. A three-day event charges the entry fee once and timing three times.

A per-entry or percentage charge counts as entries are paid, because only money received is due (see What Is Due to the Organiser). A fixed, per-service, per-participant or hand-entered charge counts when it is recorded against the event. Each charge posts when it counts; a change posts the difference.

The organiser needs a tax invoice for the service provider’s charges. It is raised in the service provider’s accounting software, not in EMS. EMS shows, on screen, each organiser’s charges not yet invoiced for a period. The operator raises the invoice in the accounting software and records its number in EMS, which marks those charges invoiced; the statement shows the invoice number against them. A file hand-off waits until the integration with the accounting software is chosen.

PAYMENT, one transaction in each company’s books, both referencing the payment. The fee shown is borne by the organiser.

Where the service provider absorbs the fee under its agreement, its provider fees expense takes the fee in place of due to organiser, and the organiser’s books carry no fee.

A receipt into the organiser’s own processor posts once, in the organiser’s books, as in Payment.

PAYMENT, on the same payment, for the difference only: the fee account (or due to organiser and the mirrored organiser entries, when the organiser bears it) against the processor receipt account.

TRANSFER, in the processor owner’s books only: debit the target processor’s receipt account, credit the source processor’s. A payout fee debits bank charges and credits the source processor. Neither party’s position moves: a payout changes where the collector’s money sits, not what it owes.

The balance held at each processor is its receipts, less fees, less transfers out. It is tracked per processor, not per event: one payout covers every event’s money in the account.

CHARGE, in both companies' books.

When the organiser’s money is in its own processors, the same postings take the pair accounts the other way: the organiser owes the service provider. One pair of accounts covers both directions.

SETTLEMENT, recorded by hand after the transfer is made in online banking. EMS records the payment; it does not make it. It carries the date, amount, bank reference and the service provider’s bank account, and either names the event or events it is for or is marked an advance — a payment made while entries are still open.

An advance may take the balance in the service provider’s favour for a time. A mistaken disbursement is reversed by a further entry, never deleted.

SETTLEMENT: the service provider pays a supplier for the organiser, at cost — an invoice in the organiser’s name. SP: debit due to organiser, credit its bank account. Org: debit event expenses, credit held by service provider. It is neither the service provider’s income nor its expense.

A cost the service provider recharges — with a margin, or a service it bought in — is a service charge on the entered by hand basis instead: its income, and on the tax invoice.

REFUND, from the processor the money was received into. Where that is the service provider’s: SP debits due to organiser and credits the processor receipt account; Org debits income (or customer credit, for an overpayment returned) and credits held by service provider. The provider does not return its original fee, so the organiser bears it.

A refund after the event has been paid over can take the balance in the service provider’s favour. It is recovered on the next statement, or invoiced if nothing further is due.

SETTLEMENT: the organiser pays the service provider in advance for services. SP: debit its bank account, credit due to organiser. Org: debit held by service provider, credit its bank account. Charges then draw the deposit down as they post. Deposits are taken only from organisers, never from participants.

A rider pays R100.00 through the service provider’s Payfast account. Payfast charges R5.00. The registration charge is R8.00 per paid entry. The service provider then pays the organiser over.

Service provider’s books:

Due to organiser ends at zero; the service provider keeps R8.00 income in its bank account.

Organiser’s books, with the sale posted when the entry was paid:

Income R100.00, expenses R13.00, R87.00 in the bank, and nothing held by the service provider.

Each posting line carries its event, so an event’s contribution — received, fees, charges, net — and a series roll-up come from the event tag on each line. Disbursements settle the balance between the companies, not a particular event; one may name the events it is for, which lets an event be shown as settled.

An Income and settlement screen in the admin portal, in the organiser’s tenant, per event with a series roll-up. The service provider operates it on the organiser’s behalf until organisers become administrators of their own tenants; tenant scoping from the start makes that a read-only role rather than a rework. The organiser receives the settlement statement — a PDF or export — with each disbursement and at close-out.