For merchants
Collect, refund, settle.
A dashboard for payments, refunds, disputes, payouts, and KYC. Fees and the settlement delay sit on the merchant account, not on each customer.
Ghana · West Africa
Accept payments on your website. Settle in cedis.
CediGate is checkout software for businesses. A shop, agency, school, or any seller online embeds one API or a hosted widget. Their customers pay with mobile money, a card, or a bank debit. The business gets one dashboard, one settlement clock, and a payout to its own bank account.
The customer pays the merchant. They do not open a CediGate account. Licensed banks authorise and settle the funds. CediGate is the merchant layer in front of those rails.
Hosted checkout
Makola Provisions
GHS 85.00
The customer approves a prompt on their phone.
The customer stays on the merchant’s site. CediGate opens hosted checkout, waits for authorisation, then posts a signed webhook to the merchant’s server.
Public summary. Full documentation, merchant guides, and the materials for bank and regulatory onboarding are being prepared. This page describes the project as it is designed.
The project
One merchant API. Banks stay behind it.
CEDIGATE LIMITED is a Ghanaian company building software and electronic-payment services for businesses. The product lets a merchant accept mobile money, card, and bank-debit payments on the merchant’s own website or application, then settle those funds through licensed banks and payment service providers.
A merchant embeds CediGate checkout — an API call or a hosted widget — on their site. The payer pays that merchant. CediGate talks to the acquiring bank. The bank authorises the charge. CediGate records the gross amount, the fee, and the net, then notifies the merchant. After the settlement delay, typically the next business day, the net is paid to the merchant’s nominated account. Company fees are withheld and paid to CEDIGATE LIMITED.
Primary customers are merchants and the developers who run their sites. Payers do not register. Switching or adding an acquiring bank does not change the merchant’s keys, payloads, or checkout.
For developers
One integration.
Drop in the checkout widget, or call the payment API from any HTTP client. Sandbox and live use the same requests. The key tells CediGate which mode you mean.
For customers
Pay and leave.
They choose MTN, Telecel, AirtelTigo, a Ghanaian bank account, or a card. Approval is a handset prompt, a bank OTP, or 3-D Secure. No wallet signup.
Coverage
Built in Ghana. Made for West Africa.
CediGate starts where Ghanaian shops already sell: mobile money, cards, and bank debit, settled in cedis. The same merchant API is shaped so a later charge in naira or West African CFA francs does not require a second integration. Accra is the centre. The coast is the map.
- Ghana first. MTN MoMo, Telecel Cash, AirtelTigo Money, Ghanaian bank debit, and cards on hosted checkout.
- One integration. NGN or XOF can be added later without rewriting keys, webhooks, or the widget.
- Local rails. Each charge is routed to an acquiring bank. The merchant still sees one status, one reference, and one settlement clock.
Home market and the region the API is built for
- Ghana · home
- Nigeria
- Côte d'Ivoire
- Senegal
- Burkina Faso
- Togo
- Benin
- Liberia
- Sierra Leone
- Gambia
Ghana is the live design centre. The other markets are the coverage the merchant API is prepared to grow into, on local rails, without a new checkout.
Payment methods
The rails Ghanaian buyers already use.
CediGate offers those rails on one checkout. Each successful charge returns one status and one reference. The customer’s approval step depends on the rail.
Mobile money
MTN, Telecel, AirtelTigo
The customer approves an STK-style prompt on their phone. This is the default rail for retail, delivery, and everyday checkout. The merchant passes a phone number as the customer identifier.
Bank debit
Ghanaian bank account
Direct debit against a bank account, with an OTP challenge. Account-name lookup runs before a payout. Useful for invoices, school fees, and larger tickets.
Cards
Visa and Mastercard
3-D Secure is required. Card data stays tokenised on the acquiring rail. CediGate is designed for PCI SAQ A: the merchant site does not store a card number or CVV.
How it works
From checkout to the merchant’s bank.
The merchant integrates CediGate once. CediGate talks to banks. The dashboard shows the payment, the fee, the net, and when the payout should land.
-
1
Start a charge. The merchant’s server calls the payment API, or the page loads the checkout widget with a public key. Amounts are minor units: 8500 is GHS 85.00. The minimum is GHS 1.00.
-
2
The customer pays. Hosted checkout offers MoMo, bank debit, or card. They approve a handset prompt, a bank OTP, or 3-D Secure. If no method is sent, the customer chooses on checkout.
-
3
The bank confirms. A callback from the acquiring bank marks the payment successful or failed. In sandbox, while bank adapters are simulated, checkout can approve or decline a test charge without moving real money.
-
4
The merchant is notified. The ledger credits the pending balance. CediGate posts
charge.successto the merchant’s webhook URL, signed, and retries if the server does not answer. -
5
The merchant is paid. After the settlement delay — one day by default — CediGate batches the net amount to the payout account on the merchant’s settings. Fees stay with CEDIGATE LIMITED.
Example initiate
POST /api/v1/payment/initiate
Authorization: Bearer sk_test_...
{
"amount": 8500,
"currency": "GHS",
"email": "ama@shop.gh",
"method": "mtn",
"customer_identifier": "0244000000",
"return_url": "https://shop.gh/thanks",
"metadata": { "order_id": "SO-1042" }
}The response includes a reference and a checkout_url. Fulfil the order only after a signed webhook, or a server-side verify, says the charge succeeded. The browser callback is for the customer’s screen.
The platform
What sits around the charge.
The payer never sees this. Merchants, their developers, and CediGate operations do.
Hosted checkout and widget
A public key in the browser opens checkout in an overlay. A secret key on the server starts the same checkout and returns a URL. Any site that can load a script or make an HTTP call can use it.
Merchant API
Initiate a payment, verify it by reference, refund in full or in part, read pending and available balance, and queue a payout. Optional request signing uses a timestamp and HMAC.
Webhooks
An HTTPS URL on the merchant account receives charge.success, charge.failed, and test events. Each delivery carries an event name and an HMAC signature. Failed deliveries are retried.
Keys
Sandbox keys (pk_test_, sk_test_) are issued when the merchant activates their email. Live keys follow KYC approval. Secret keys are shown once and stored as a hash. A suspended account cannot charge.
Merchant dashboard
Search payments, refund from a payment, open a dispute with written evidence, read settlement batches, manage webhook deliveries, upload KYC, and store the payout account.
Operations console
CediGate staff review merchants and KYC, inspect transactions, refunds, disputes, settlements, and platform revenue, and keep an audit log of sensitive actions.
Ledger
Each successful charge writes the gross, the fee, and the net. Balances move from pending to available after the settlement delay, then to a payout batch. Refunds and disputes can reverse a paid charge.
Fraud checks
Before a charge is accepted, CediGate scores amount, recent velocity, and repeated failures from the same customer, plus rules configured for that merchant.
Money
Fees come off the charge. The merchant receives the net.
CediGate does not hold a consumer balance. A successful charge is the merchant’s money, minus the fee, waiting out the settlement delay. Payouts go to the bank account the merchant named in settings, after an account-name check.
- Currency. Ghana cedis are the home currency. Amounts on the API are integers in pesewas.
- Clock. The default settlement delay is T+1. The delay lives on the merchant account.
- Payout. Available funds are batched and credited to the merchant. Company fees are paid to CEDIGATE LIMITED’s own account.
- Refunds. A full or partial refund can be started from the dashboard or the API. A dispute records evidence against a charge.
T+1
Default settlement delay before a successful charge becomes available to pay out.
GHS
Home currency. The API also recognises NGN, XOF, and USD for later corridors.
SAQ A
Card numbers are not stored. The merchant’s page never sees a PAN or CVV.
Indicative fees
Sandbox defaults that mirror a typical Ghana mix.
These figures are the product’s sandbox defaults, taken off each successful charge before settlement. There is no monthly platform fee in sandbox. Live rates are commercial and are set with the acquiring banks. They are not a published tariff.
Local MoMo
1.95%
MTN, Telecel, and AirtelTigo. Settled on the merchant’s T+1 clock.
Bank debit
1.50%
Direct debit with OTP. Account-name lookup is part of payout.
Cards
2.90% + GHS 0.30
Visa and Mastercard. 3-D Secure required. PCI SAQ A design.
Boundaries
What CediGate is, and what it is not.
What the company does
- Develops and licenses checkout software, APIs, and a hosted payment page for businesses.
- Collects MoMo, card, and bank-debit payments for those merchants, including refunds, settlement reporting, and webhooks.
- Connects merchants to licensed banks, payment service providers, and electronic-money issuers for authorisation, clearing, and settlement.
- Instructs those banks to credit the merchant’s payout account and the company’s fee account.
What the company does not do
- It does not carry on banking business.
- It does not take deposits from the public.
- It does not operate a consumer wallet or a peer-to-peer transfer service.
- Customers of merchants do not open accounts with CediGate. Funds are authorised and settled by licensed banks and payment service providers.
Security and control
Designed so the merchant site never holds the sensitive data.
Keys and requests
Server calls use a secret key as a bearer token. The public key is only for the widget. Request signing, when used, is HMAC-SHA256 over the timestamp and the raw body, and the timestamp must be recent. Keys can carry an IP allowlist. The API is rate limited.
Cards and payout accounts
A card charge sends an acquirer token, never a PAN or CVV. Payout account numbers are stored encrypted. Name enquiry runs before money is sent to a merchant account.
Going live
Live keys are issued only after KYC: incorporation, TIN, registered office, and director identification, reviewed by CediGate operations. Sandbox and live share the same API, so going live is a key change, not a second integration. Real MoMo, cards, and bank debit also depend on the acquiring bank being connected.
Where things stand
This site is the summary. The rest is being prepared.
The product is built as a merchant platform: checkout, API, dashboard, ledger, settlements, KYC, and an operations console. What is still being assembled for partners, banks, and the public is the documentation set and the company, banking, and regulatory materials required before live acquiring.
In the product
Hosted checkout, the merchant API, sandbox keys, webhooks, refunds, the settlement ledger, fraud scoring, and the merchant and operations dashboards.
Being prepared
Public documentation and merchant guides, company filings, and the onboarding pack for acquiring banks and the Bank of Ghana payment-service path.
Before live money
Approved KYC, a signed integration with a licensed acquirer, and the payment-service position that bank and Bank of Ghana advice require. Until then, sandbox is the working environment.
Questions
What this page is usually asked.
No. Only the business signs up. The customer pays on the merchant’s site and leaves.
None. The merchant integrates CediGate. Acquiring banks are adapters behind that API. Adding another bank does not change the merchant’s keys or payloads.
A successful charge sits in pending, then becomes available after the settlement delay on the account. The default is T+1. Payouts go to the bank account stored in settings.
Yes. A refund can be started from the payment in the dashboard or from the API, in full or in part. Disputes have their own record, with a place to submit evidence.
CediGate posts JSON to the merchant’s HTTPS webhook URL with an event name and an HMAC signature, and retries failed deliveries. The merchant can also verify a reference from their server. The browser success callback is not enough to fulfil an order.
Email enquires@cedigate.com. Include your business name and whether the question is about checkout, settlement, or documentation.
No. It does not take deposits, it does not run a consumer wallet, and it does not move money person to person. Customers do not hold a balance at CediGate. Licensed banks and payment service providers authorise and settle the funds.
Enquiries
Write to CediGate.
Merchants, developers, and partners can send questions to enquires@cedigate.com. Include your business name and what you need: checkout, settlement, or documentation.