Docs menuDealer accounts

Concepts

Dealer accounts

Face value by default; a verified business buys below face and funds by cash collection.

Every organisation starts on the standard tier: it buys at face value, with no paperwork, from its first key. A business that Jusa staff have verified can move to the Dealer tier and buy below face, at rates set for it when it is approved. Nothing about the standard tier changes because the Dealer tier exists.

The two tiers

StandardDealer
WhoEveryone, from the first key. No checks.A registered business, verified by Jusa staff from its documents.
PriceFace value: a US$0.50 reward costs US$0.50.A discount off face per network and currency, set on approval. It is taken as a lower debit of Jusa Credit when the send is made, never paid out later.
FundingCard (Pesepay) or bank transfer.Cash collected by Jusa staff; card and bank transfer still work.
GET /account"tier": "standard", "dealer": null"tier": "dealer", "dealer": {"rates": …, "since": …}

Applying

From your live organisation, with a secret or restricted key (an agent key cannot apply; a sandbox never applies, its live organisation does):

  1. POST /dealer/application with company_name, registration_number, tax_number (optional), contact_name, contact_phone, address and notes (optional). It answers 201 with a dealer_application (dap_…, "status": "submitted"). One application is open at a time (409 dealer_application_open), an organisation that is already a dealer does not apply again (409 already_dealer), and a test key gets 409 sandbox_cannot_apply.
  2. POST /dealer/application/documents, multipart with kind and file, once per document (a PDF, JPEG or PNG up to 10 MB). Kinds: incorporation_certificate, directors_list, director_id, proof_of_address, bank_letter, tax_clearance. The application lists what you sent under documents; only your organisation and Jusa staff can open the files.
  3. Wait. GET /dealer/application shows the current application (404 when there is none), and GET /account says "verification_status": "pending". POST /dealer/application/withdraw takes it back (409 dealer_application_not_open once it is decided).
  4. Jusa staff read the documents and approve the application with your rates, or reject it with a reason you see on the application. Either way the event dealer.application.decided carries the application to your webhook endpoints, and verification_status becomes approved or rejected.

verification_status is not_required for a standard organisation that never applied (or withdrew), so nothing is pending on an account that does not want the Dealer tier.

Rates

Rates are set per organisation when it is approved; they are not published here. Each is a percentage off face, two decimals, from 0.00 to 20.00, per currency and per network: econet, netone, telecel, zesa, telone, other. GET /account shows yours as "dealer": {"rates": {"USD": {"econet": "3.00", "zesa": "1.00"}, "ZWG": {…}}, "since": "…"}. A network or currency that is not listed is at face. Airtime is priced at the network the number belongs to. Jusa staff can change the rates later; a send keeps the cost it was debited at.

What a send costs

cost = face × (100 − rate) ÷ 100, to the cent, rounded half up. Quotes, the ZESA quote, sends and the items of GET /sends carry it:

  • "cost": {"amount": "9.70", "currency": "USD"}: what your Jusa Credit was (or would be) debited.
  • "dealer_discount": "3.00": the percentage applied.

On the standard tier cost equals the face value and dealer_discount is "0.00", so one integration reads both tiers. The person on the other end gets the full face value either way. A send that fails credits back the cost, never the face. The monthly statement adds face_sold, cost_drawn and dealer_discount_earned, and the statement PDF prints them for dealers.

Cash collections

Dealers fund by cash, collected by Jusa staff:

  1. POST /credit/topups with "method": "cash", amount, currency (USD or ZWG), address, contact_phone and an optional window (when to come). The top-up is pending and credit.topup.pending fires.
  2. Jusa staff collect the cash, count it, and confirm the collection in the console with the counted amount, the denominations, a note and the time.
  3. Credit posts only on that confirmation, for the counted amount. The top-up becomes paid, credit.topup.succeeded fires, and its cash block says address, contact_phone, window, counted_amount and collected_at. A pickup staff cancel is failed, with the reason; a pending pickup never expires on its own.

Live cash is for the Dealer tier only: a standard organisation gets 400 method_not_available and uses a card or bank transfer. Dealers can still use a bank transfer or a card; nothing blocks them.

In test mode

Your sandbox mirrors your live terms: once you are approved, a test key sees "tier": "dealer" and the same rates in both currencies, and test quotes and sends price at them. The sandbox holds both a USD and a ZWG balance (US$1,000 and ZWG 25,000, topped up daily), so ZWG quotes, sends, statements and cash pickups work as they do live. A test-mode cash pickup confirms at once for the amount asked, on any tier, so you can see the shape before you apply. See test mode.