Online checkout
Take payment on your website or in your app — through a page we host and keep accessible, or against the API if you would rather build it yourself.
E-commerce · SaaS · travel · donations
One contract MTN, Airtel and bank rails behind it
One integration.
One integration.
Every customer
in Uganda.
A supermarket in Kampala, a school collecting fees, a payroll of four thousand, or a software company in Nairobi, Lagos or London selling to Ugandans. If your customers are here, JCREDO connects you to MTN Mobile Money, Airtel Money and partner banks through one contract.
From one integration
MTN · Airtel · Bank
Ways to get paid
Checkout · QR · Links · API
Rails
MTN Mobile Money, Airtel Money and partner bank channels
Ledger
Immutable double-entry. Balances are derived, never edited
Contract
Provider-neutral. Rails change without you reintegrating
Reach
Built in Kampala. Used from anywhere your customers are not
Solutions
Pick the one that sounds like your week.
The same rails and the same ledger underneath. What changes is the shape of the problem you brought.
QR at the till
A code at the counter, the payment on the customer’s own phone, and the sale on your dashboard before they have put it back in their pocket. One code for the counter, paused or revoked from the console the moment you need to.
Supermarkets · retail · restaurants · fuel
Payment links
Send a link over WhatsApp or SMS and get paid. Fixed amount or open, single use or reusable, and no website required to start.
Traders · services · freelancers
Bulk payments and payroll
Thousands of recipients from one file, validated before a shilling moves. Prepared by one person, approved by another, with the funding reserved first.
Employers · NGOs · agri buyers · insurers
School fees
Fees collected per student and per term, each payment carrying the reference you gave it — so the bursar’s list and the ledger agree.
Schools · universities · training
Invoices and recurring billing
Issue an invoice with a due date, send the link, and match the payment to the invoice that caused it.
Utilities · subscriptions · B2B · rent
Multi-branch businesses
Every transaction carries the branch it belongs to, so head office sees each branch’s takings and the whole, without anyone re-keying a figure.
Chains · franchises · agent networks
Platforms and marketplaces
Give your own product a payments layer through the API and signed webhooks, and pay any other business on JCREDO instantly, settled on our ledger.
Marketplaces · software vendors · fintechs
Built with JCREDO
Edumaster
Our own online school system runs its fee collection on JCREDO — term invoices per student, mobile money from the parent’s own phone, and a reconciliation that names the pupil rather than the transaction. It is the proof that the school-fees path is a product and not a slide.
Why JCREDO
Most payment dashboards
lie by simplifying.
A payment has five independent lifecycles. Collapse them into one status and the screen will eventually tell someone the money arrived when it did not. JCREDO renders all five separately — and each one shaped and labelled differently, so colour is never the only thing carrying meaning.
01
Payment
SUCCEEDEDDid the payer actually get debited on the rail.
02
Ledger
POSTEDWhether the double-entry journal for it exists yet.
03
Webhook
FAILED_RETRYABLEWhether your systems have been told, and succeeded.
04
Settlement
INSTRUCTION_PENDINGWhether the money has reached your own bank account.
05
Reconciliation
UNMATCHEDWhether our record and the operator's record agree.
A payment that has SUCCEEDED on the rail and is UNMATCHED in reconciliation is a real and common situation. One number cannot say both. So we never make it try.
The platform
Everything it takes to move money in Uganda.
Collections, payouts, settlement, reconciliation and a developer platform — one account, one ledger, one place to look when someone asks what happened to a payment.
01
Collect from anyone with a phone
Push a prompt to a payer's handset, or send them somewhere to pay. Every collection lands in the account you choose and posts to the ledger the moment it is real.
- Hosted checkout — a payer page we host, keep accessible and keep honest
- Payment links and QR codes — one amount or open, single use or reusable
- Invoices — issue, track and reconcile against the collection that paid them
- Refunds and reversals — linked to the original, never an edit of it
Transactions · payment and ledger state, kept apart
02
Pay out to one person or ten thousand
Salaries, supplier payments, grant disbursements, refunds. Prepared by one person and approved by another, with funding reserved before anything leaves.
- Bulk upload — thousands of rows, validated before a single shilling moves
- Maker-checker approvals — thresholds you set, and nobody approves their own
- Scheduled and grouped payouts — payroll that runs on the day it should
- Saved beneficiaries — masked by default, revealed only with permission and an audit note
Payouts · approved and funded are two different facts
03
Know where you stand, to the shilling
Available now, pending settlement, and reserved against payouts you have already approved — three different numbers, shown as three different numbers.
- Settlement batches with the postings that made them, not a summary
- Reconciliation exceptions — real disagreements with the operator, listed and workable
- Fees shown per transaction, so the figure you reconcile is the figure you were charged
- Exports and a report catalogue your accountant can actually use
Overview · available, pending and reserved, never one number
The hard part
A timeout is not a failure.
Mobile money networks go quiet. When that happens, most platforms guess — and the usual guess is “failed”, which is how a customer gets asked to pay a second time for something they already paid for. Getting that money back takes days.
JCREDO treats UNKNOWN as a real state with its own colour, its own glyph and its own words. It is never styled as an error. And on an unknown payment, the retry button is not greyed out — it is absent, because a disabled button is still an invitation.
UNKNOWN · still confirming
We are still confirming this payment
An unknown outcome means we do not yet know whether the payer was debited. Do not ask the payer to pay again.
Amount in questionUGX431,000
Last known factRAIL_ACK · 05:34 EAT
Operator re-queriedevery attempt recorded
There is no retry control on this payment. A second request would be a
second real debit.
Rails
Every rail Uganda pays on. One contract.
MTN Mobile Money, Airtel Money and partner bank channels behind one contract and one API, with each operator’s own callbacks driving state. Direct operator agreements are being established, and nothing in your integration depends on which path a payment takes.
MTN Mobile Money
Collections and payouts to MTN Mobile Money accounts, with the operator's own callbacks driving state rather than a polling guess.
Airtel Money
The same canonical contract as MTN. Your integration does not change when the rail does — that is the whole point of it.
Partner banks
Bank transfers for settlement and for payouts that belong on a bank account rather than a wallet.
Rail health is shown in the console as its own fact — operational, degraded, down, or unknown. A rail we cannot currently measure is never drawn as a healthy one.
Based in Uganda
Collect from customers, pay suppliers and staff, and settle to your Ugandan bank on the cycle you agree with us.
Selling into Uganda
Your customers pay the way they already pay — their own wallet, their own phone — while you integrate once and read one API.
Building for others
Give your own product a payments layer: one API, signed webhooks, and instant payments to any other business on JCREDO.
Developers
One contract.
Every rail behind it.
A REST API that speaks in canonical terms, never in an operator's vocabulary. Integer minor units with an ISO 4217 code — never a float. Idempotency on every mutating call, because a retried request must not become a second payment.
01
Signed webhooks, with delivery you can see
Every attempt, every response code, every retry — listed in the console, replayable, with secrets you rotate yourself.
02
A sandbox that behaves like the real thing
Including the states nobody simulates: declines, expiries, reversals, and payments that go quiet.
03
Request logs and API usage, per credential
A log of what you actually sent us, kept for the retention window shown in the console, so “it worked yesterday” is a question with an answer.
# Ask a payer on MTN or Airtel to approve a payment. curl -X POST https://jcredo.320tech.io/v1/collections \ -H "Authorization: Bearer $JCREDO_API_KEY" \ -H "Idempotency-Key: 8f2a1c40-3d5e-4b19-9c77-ae20f1d84b03" \ -H "Content-Type: application/json" \ -d '{ "merchantReference": "INV-20451", "money": { "amountMinor": "250000", "currency": "UGX" }, "method": "MOBILE_MONEY", "payer": { "phoneNumber": "+256700000000" } }' # 201 Created { "id": "col_01JK7Q1B4XD2", "merchantReference": "INV-20451", "money": { "amountMinor": "250000", "currency": "UGX" }, "status": "CREATED", "createdAt": "2026-10-31T09:24:11Z" } # CREATED is not SUCCEEDED. Wait for the webhook — # and if it ever says UNKNOWN, do not charge again.
Controls
Built for the day something goes wrong.
Most of what a payment platform owes you only matters once — on the day a dispute, a mistake or an insider costs real money. These are the parts that are there for that day.
Nobody approves their own payout
Maker-checker is domain logic, not a token claim. The person who prepared a payment cannot be the person who releases it, and the control cannot be turned off by one person acting alone.
A code for the money, to the right person
Payouts above the threshold you choose ask the approver for a one-time code — sent to the address on their own record, never one the request names, and bound to that exact amount and destination.
Destinations masked by default
Phone numbers and account numbers are masked everywhere, including in exports. Revealing one needs a permission, captures a purpose, is written to the audit log, and re-masks itself.
An audit log that records refusals too
Who did what, when, from where — and just as importantly, who tried and was refused. Entries are append-only and carry the reference of the thing they acted on.
Roles that match how your business runs
Owner, Finance, Operations viewer, Payout approver, Developer — with branch labelling, invitations, and a console that hides what a person may not do rather than offering it and refusing later.
No state editing. Anywhere.
There is no screen in JCREDO that lets anyone set a payment's status by hand or adjust a balance. Corrections are linked reversals that leave both entries standing.
Who it is for
The people on the other side of the API.
Somebody with a shop to run, a payroll to make, or a term’s fees to reconcile — and the product manager two time zones away whose customers are all of them. These are the situations the console was designed around.
Most of Uganda’s commerce happens at a counter, and settles on a phone.
Collections · MTN and Airtel · one list
Owner · hardware retail
Checks on a Sunday whether Friday’s collections settled, from a phone, without having to call anybody.
Finance lead · logistics
Releases the payout run, and needs to see the funding reserved before she approves it rather than after.
Trader · Kikuubo
Takes MTN and Airtel all day and wants one list of what came in, not two statements to add up by hand.
Vendor · produce market
Sends a payment link over WhatsApp and knows within seconds whether it was actually paid.
Branch manager · three outlets
Reads his branch’s takings in the console, because every transaction carries its branch.
Operations · school group
Reconciles ten thousand fee payments a term against the students who actually paid them.
These photographs are stock images, chosen to show the situations JCREDO is built for. They are not customers and these are not testimonials. When real merchants agree to be named and quoted, their words and their faces will replace these together.
Sectors
Retail and e-commerce
Schools and tertiary institutions
Utilities and billing
NGOs and grant disbursement
SACCOs and microfinance
Logistics and delivery
Retail and e-commerce
Schools and tertiary institutions
Utilities and billing
NGOs and grant disbursement
SACCOs and microfinance
Logistics and delivery
Payroll and gig platforms
Events and ticketing
Insurance and health
Agriculture and produce
Healthcare and clinics
Payroll and gig platforms
Events and ticketing
Insurance and health
Agriculture and produce
Healthcare and clinics
Questions
The things people ask before signing.
Getting started
What do I need to open an account?
A registered business, its certificate of incorporation or registration, a TIN, the IDs of the directors or owners, and the bank account you want settling into. You submit all of it from the console, and you can see exactly where the application stands at any time.
My company is not in Uganda. Can I still use JCREDO?
That is a large part of what we are for — if your customers are in Uganda, you do not have to be. What we verify about you depends on where you are registered, and the documents we ask for differ by jurisdiction, so tell us where the company sits when you apply and we will tell you what we need and where we can settle. We would rather answer that honestly up front than after you have built.
How long does onboarding take?
You can start building against the sandbox on day one — it needs nothing from compliance. Going live depends on verification of your documents and on the operator approvals for the rails you want. We show you which step you are on rather than asking you to call and find out.
Is there a sandbox, and is it honest?
Yes, and it is the same code path as production with the rails replaced. It can produce declines, expiries, reversals and unknown outcomes on demand, because an integration that has only ever seen success is an integration that has not been tested. Every sandbox screen in the console carries a banner saying nothing there reaches a real wallet.
What does it cost?
Pricing is per transaction and depends on the rail and your volume. Fees are shown against each transaction in the console, so the figure you reconcile is the figure you were charged. Tell us what you move and we will quote it properly rather than publish a number that will not apply to you.
How it works
Which rails can I reach?
MTN Mobile Money and Airtel Money for collections and payouts, and partner bank channels for settlement and for payouts that belong on a bank account. You integrate once against our contract; when we add or change a rail behind it, your code does not change.
What happens when a payment is UNKNOWN?
It stays UNKNOWN until we know. We keep querying the operator, the amount is shown as in question rather than counted as yours, and the console shows every query we have made. What it does not do is offer a retry, because a second request on a payment that may already have debited the payer is a second real debit.
When do I get my money?
Collections post to your JCREDO account as they confirm, and settle to your bank on the cycle agreed with you. The console separates what is available now, what is pending settlement, and what is reserved against payouts you have already approved — because treating those three as one number is how businesses overcommit.
Who can move money, and can I limit it?
You set roles per person, and a threshold above which a payout needs a second person to approve it. Above a second threshold, the approver is also asked for a one-time code sent to their own address. Raising those thresholds, or switching the control off, takes two people — one of them cannot be the person who proposed it.
Can one account cover several branches or several businesses?
Branches are built in: every transaction carries the branch it belongs to, so head office sees each branch’s takings and the consolidated whole without anyone re-keying a figure. A business can also hold more than one JCREDO account for a different currency or purpose, and businesses on JCREDO can pay each other instantly, settled on our ledger rather than through the banking system.
Can I see what my own integration sent you?
Request logs per credential for the retention window shown in the console, every webhook delivery attempt with its response code, and an append-only audit log of every action taken in the console — including the ones that were refused.
Get started
Tell us what you move.
JCREDO accounts are opened by application rather than sign-up, because moving other people's money requires us to know who you are. It is a short form and a real person reads it.
1
You tell us about the business
What you do, roughly what you move each month, and which rails you need.
2
We open your sandbox
Credentials the same day, so your developers can start while compliance runs in parallel.
3
You submit the documents
From the console, with a screen that always says where the application stands.
4
You go live
Same code, same contract, real money, once your live credentials are issued. The banner at the top of every screen changes.
Thank you — that has reached us.
We read every one of these ourselves. Expect a reply from a person, not an autoresponder, within one working day. If it is urgent, call the number in the footer.
Contact
Talk to a person.
Money questions do not wait for office hours and they do not suit a ticket queue. Pick whichever of these you already have open.
WhatsApp
Message us
Fastest during the working day
Telegram
@jcredo
Good for developers mid-integration
Email
info@jcredo.320tech.io
A reply from a person, within a working day
Phone
+256 753 479 192
Mon–Fri, 08:00–18:00 EAT
- Office
- B02 Mabirizi Complex, Kampala, Uganda
- Hours
- Monday to Friday, 08:00–18:00 East Africa Time. Payment incidents are watched outside those hours.
- Already a merchant?
- Raise it from inside the console — it arrives with your account and the transaction already attached. Log in.
Already building? Go straight in.
The console, the sandbox and the API reference are behind one login.