Collect payments

The four ways to take a payment, what each costs you in code, and what follows.

Taking a payment with Wajub is always the same transaction underneath. What differs between the four integration modes is who renders the screen where the customer confirms, and therefore how much of the payment experience you own and have to maintain.

Pick by that question alone. Everything else, the operators you reach, the webhooks you receive, the refunds you can issue, is identical across the four.

Four ways in

Each mode produces a different screen for your customer, and that is the whole difference. Below is what each one actually looks like once it is live.

Recommended

Hosted Checkout

Create the payment, redirect to the authorization_url, handle the webhook. Wajub renders operator selection, the prompt and the result.

In your page

Embedded Components

The same checkout, mounted inside your own layout with the session token. React, Vue, Svelte or vanilla JS.

No code

Payment Links

A shareable URL or QR code, no integration at all. Production only, and 25 links on the Pay as you go plan.

Full control

Direct API

You collect the number and call POST /payments/{id} yourself. The prompt lands on the handset, you render everything else.

Undecided? Choose your integration compares the four on code, customisation and use case. If you would rather see one work before choosing, the Quickstart takes a sandbox payment from nothing to a verified webhook.

Payment methods

Mobile Money is the backbone: MTN, Orange, Wave, Airtel, Moov and M-Pesa, across a dozen countries. Cards and domestic bank transfers are available where the operator supports them. Channels are named country.operator, so cm.mtn is MTN Mobile Money in Cameroon and sn.wave is Wave in Senegal.

The full country and operator matrix is in Payment methods & channels, and the number formats each operator accepts are in Phone number formats. Get the number format wrong and the payment fails before the customer ever sees a prompt, so that second page is worth reading once.

The two calls

Creating a payment never charges anyone. POST /payments records the intent, holds it pending, and hands you back a hosted page URL and a browser-safe session token. Nothing has reached an operator yet.

What charges is the second call, and three of the four modes make it for you. Hosted Checkout makes it when the customer taps confirm on the Wajub page, Components makes it from inside your page, and a Payment Link makes it on its own hosted page. Only Direct API leaves it to you: you collect the phone number yourself, then send POST /payments/{id} with a channel and the payment details, and the prompt goes out to the customer's handset.

A private key in a browser is refused

Never use sk.… from a browser. When Wajub detects it, the request is rejected with a 403 and the key's owner is emailed. Direct API therefore belongs on your server. Front-end code uses the public key, or the session token the create response returns.

API resources

Payments share one API with every other product. These are the resources this one calls; the full parameters and responses are in the API reference.

Endpoint	Methods	Used for
`/payments`	`GET` `POST` `DELETE`	Create, list, retrieve and cancel a payment
`/payments/{id}`	`POST`	Charge it on a channel, and its `/splits` for instalments, on Mobile Money in live
`/refunds`	`GET` `POST`	Issue a refund and follow it
`/customers`	`GET` `POST` `PUT` `DELETE`	Returning customers, plus block and deactivate
`/disputes`	`GET` `POST`	Evidence, acceptance, closure and messages
`/links`	`GET` `POST` `PUT` `DELETE`	Payment links. Production only

Standard payment calls need no product-specific header. A marketplace attributing the payment to one of its subaccounts adds X-Sync: acc_… to the same call, as described in Sync → API resources.

After the payment

Need	Where
Know the outcome as it happens	Webhooks
Understand each state and its transitions	Payment lifecycle
Refund a payment	Refunds
Handle a dispute or a chargeback	Disputes
Recognise a returning customer	Customers
Decide between webhooks and polling	Webhooks vs polling