Collect payments

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

Four ways to take a payment, which differ only in who renders the screen where the customer confirms. The operators you reach, the webhooks you receive and the refunds you can issue are the same in all four.

Four ways in

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, Angular 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. Hosted Checkout, Components and Payment Links make it for you. 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.

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
`/payments/{id}/activate`	`POST`	Create a payment prepared with `deferred: true` once the order is placed, for payment fields shown before the order exists. Before that, `PATCH /payments/{id}` changes its amount
`/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