Glossary

The words this documentation uses, defined once, with the traps named.

Payments vocabulary is full of words that mean something slightly different at every company, and African payments adds a layer on top. This page defines the terms as Wajub uses them, and calls out the three or four where an assumption from another platform will cost you.

If you are reading the documentation for the first time, the six entries marked as traps are the ones worth reading now. The rest you can come back to.

Payments and collection

Term	What it means here
Payment	One collection attempt, with an id and a status. The API also calls it a transaction, and the two words are the same object. See Payments.
Channel	The concrete payment method, written `country.operator`, as in `cm.mtn` or `sn.wave`. See Payment methods.
Authorization URL	The single-use link to the hosted page where the payer completes the payment. It expires with the payment.
Session token	`authorization_token`, the same session in token form, safe in a browser because it is scoped to one payment and nothing else.
Customer	A reusable payer, identified by email or phone. See Customers.
Refund	Money sent back on a succeeded payment. Its own object, its own status, its own webhooks. See Refunds.
Dispute	A payer contesting a payment they made. See Disputes.
Bearer	Who pays the fee on a payment, `merchant` or `customer`. With `customer`, the fee is added to what the payer is asked for.

Trap: `reference` is yours, `id` is Wajub's

reference is a free string you attach to a payment so you can recognise it in your own system. It has no uniqueness rule, and two payments can carry the same one. id is the Wajub identifier, and it is the only value GET /payments/{id} resolves. Looking a payment up by your own reference answers 404.

Mobile Money

Term	What it means here
Mobile Money	An e-money account attached to a phone number. MTN MoMo, Orange Money, Wave, M-Pesa and the rest. The dominant way money moves in most of the markets Wajub covers.
Wallet	One payer's Mobile Money account, named by their number in E.164 form.
USSD	The `*…#` menu a payer dials to authorise a payment without a data connection.
Push prompt	The confirmation the operator sends to the payer's phone. Sent by the operator, not by Wajub, which is why its delay is outside Wajub's control.
Transfer	Money going the other way, out to a wallet or an account. Also called a payout. See Transfers.
Beneficiary	A saved transfer recipient, reused without retyping their details. See Beneficiaries.

Trap: a Mobile Money payment waits on a human

A card is decided by a machine in about two seconds. A Mobile Money payment is decided by someone holding a phone, which is why pending is a normal state that can last minutes, and why the webhook rather than the API response is what tells you the outcome.

Money and settlement

Term	What it means here
Balance	Funds held for you by the licensed partner, split into `available` and `pending`. Only `available` can fund a transfer. See Balance.
Settlement	The step that turns a succeeded collection into spendable balance. A payment can read `succeeded` while its money is still `pending`.
Fee	What a transaction costs. See Fees.
Reconciliation	Matching what Wajub recorded against what your own system recorded, usually daily.
Partial	A payment where some but not all of the amount has been captured. On Mobile Money above 500 000 XAF or XOF, the hosted page collects in tranches and the payment sits here until the last one lands. Not a fulfilment signal.

Platform and marketplaces

Term	What it means here
Sync	Acting on another merchant's behalf after they authorised your platform. See Sync.
Connection	One authorised link between your platform and a merchant, `acc_`-prefixed. Created by you, accepted by them.
`X-Sync`	The header that attributes a call to a connection. The payment then belongs to that merchant, and your commission is credited to you.
Split payment	Two unrelated features share the word. Instalment splitting is one payer settling one payment in tranches. Per-connection pricing is your cut of a connected merchant's payment. See Split payments.

Trap: no payment is shared between several merchants

There is no feature that divides one payment's proceeds across several accounts, on any plan. A basket with several sellers is several payments, one per seller, each carrying its own X-Sync.

Technical

Term	What it means here
Orchestration	Choosing which provider a transaction is routed to, and falling over when one fails. See Orchestration.
Waterfall	The automatic retry on a backup provider after a failure. See Waterfall.
Priority tier	An integer on a provider that dominates routing. A lower tier is never tried before a higher one, whatever the cost or score.
Shield	Rule-based fraud screening: blocklists and a risk score. Live only. See Shield.
Webhook	A signed HTTP call Wajub makes to your server when something changes state. See Webhooks.
Event	One thing that happened, `evt_`-prefixed, delivered by a webhook. Its name is on the `event` field, never on `type`.
Idempotency key	A string you attach to a write so a retry of it returns the original result instead of doing the work twice. See Idempotency.
Failure reason	The stable machine code on a failed payment, transfer or refund. Branch on it, never on the message beside it. See Failure reasons.
`X-Request-Id`	The identifier of one API call, returned on every response. Send your own and it is echoed, which is what makes a support ticket quick.
Sandbox	The test environment, reached with a `pk_test.` or `sk_test.` key. A separate database, with no real money in it. See Environments.
Konsole	The request inspector: what you sent, what came back, which provider ran, whether the webhook landed. See Konsole.
KYC	The identity verification a regulator requires before your live keys can take real money. See Going live.

Identifiers

Every object Wajub creates carries an opaque id: a prefix, test_ when it was created in sandbox, then 20 or 24 random characters.

The same object in each environment

trx_CSUGajfv9xh0XQ5wu2lx        # live
trx_test_CSUGajfv9xh0XQ5wu2lx   # sandbox

The random part is random. It is not a timestamp, it does not sort chronologically, and it carries no information you can parse. Store it, do not build it and do not derive anything from it.

Prefix	Object
`trx_`	Payment
`fdg_`	Funding, a top-up of your own balance
`splt_`	Instalment split on a payment
`po_`	Transfer
`rfd_`	Refund
`dsp_`	Dispute
`cus_`	Customer
`pm_`	Payment method
`ben_`	Beneficiary
`acc_`	Sync connection
`evt_`	Event

The `test_` is the fastest bug report you will ever read

An id with test_ in it cannot be found by a live key, and one without cannot be found by a sandbox key. Either way the answer is 404, not a permission error, because the two environments are different databases. When an id you are sure about answers 404, read the prefix first.

Words this documentation does not use

Naming what does not exist saves as much time as defining what does.

You might look for	What there is instead
Bulk or batch transfers	Nothing. One `POST /transfers` per recipient. See Push.
Standard, Express or Custom accounts	Sync has three modes — `direct`, `lite`, `relay` — and they say where the money sits, not what a connection may do.
`invoice.paid`	`invoice.created`, `invoice.updated`, `invoice.deleted`. Payment outcomes arrive as `payment.*`.
Amounts in centimes	Major units everywhere. `5000` is five thousand francs.
A `409 Conflict`	Idempotency conflicts answer `422`, with the detail under `errors.idempotency_key`.