Most Kenyan businesses collect payments one of two ways: a paybill number the customer dials by hand, or an invoice sent after the fact. Both leave someone checking messages and updating a spreadsheet. A no-code form builder with M-Pesa and bank payments closes that gap: the customer fills the form, pays on the spot, and the entry is marked paid before they close the tab.
In the video above we walk through exactly this setup, from the form fields to the payment confirmation. This post covers the same ground in writing, with the links and code paths you need to build it yourself or hand it to a developer.
What a payment form actually is
Strip away the jargon and a payment form is two things combined:
- A regular online form: name, phone number, email, what they are paying for, how much.
- A payment step that fires on submit: the moment the form is sent, the customer gets an M-Pesa prompt on their phone (or shows a bank transfer option), and the form entry is tied to that transaction.
No coding is required to run one. The builder handles the fields, the payment step and the confirmation. That is the whole point of the no-code angle: a shop owner, trainer or events coordinator can publish a collecting form without touching an API.
Common uses:
- Event and workshop registration with the fee paid upfront
- School fees, training fees and course deposits
- Booking deposits for rentals, appointments and service calls
- Invoices and one-off payments for small businesses
- Fundraisers and contribution tracking
How the M-Pesa side works
The M-Pesa step uses STK Push, the same prompt you see when paying a Paybill. The flow inside the form looks like this:
- The customer submits the form.
- The server starts an STK Push to the phone number they entered, for the amount shown on the form.
- The customer enters their M-Pesa PIN on their handset.
- Safaricom sends a callback with the result.
- The form entry flips to "paid", and a confirmation goes out.
From the developer side, step 2 is one request:
app.post('/api/pay', async (req, res) => {
const { phone, amount, reference } = await validate(req.body);
const r = await mpesa.stkPush({ phone, amount, reference });
res.json({ checkoutRequestId: r.CheckoutRequestID });
});
The callback is what matters. Never trust a transaction code the customer typed into a field. Mark the entry paid only when the callback from the gateway confirms it, and make your handler idempotent so a replayed callback cannot double-record anything. We covered those rules in detail in the Daraja go-live checklist.
If you do not want to wire Daraja yourself, this is what a gateway like FortPesa handles for you: the STK Push, the callback and the verification, behind one API key.
The bank payment option
Not every customer wants to pay from M-Pesa, and larger amounts often arrive by bank transfer. The same form can offer both:
- M-Pesa: instant prompt, instant callback, entry marked paid automatically.
- Bank transfer: the form shows the account details, the customer pays and keeps the reference, and the entry lands in a pending state until someone matches the transfer.
The rule that keeps both paths honest is the same: payment status comes from the gateway callback or a matched bank statement, never from the customer's word alone.
What to look for in a no-code form builder
If you are comparing tools, these are the questions that decide whether the form actually collects money or just collects entries:
- Does payment happen on submit? The prompt should fire when the form is sent, not after a manual "I have paid" checkbox.
- Is confirmation automatic? A paid status driven by the gateway callback means nobody is reconciling by eye.
- Are both payment methods in one form? M-Pesa and bank on the same page, so the customer picks instead of bouncing between links.
- Does it work without a website? Some setups let you share a form link directly on WhatsApp, which is enough for many small businesses.
- Can you see what is owed? A simple dashboard of entries, paid and pending, beats a spreadsheet.
Who this fits
If you collect fixed amounts from people one by one, a payment form fits: organisers selling tickets, trainers taking course fees, landlords collecting deposits, service businesses taking booking deposits. If your amounts vary per customer or you need recurring billing, you are looking at an invoicing or e-commerce setup instead, which is the booking system workflow we covered before.
Build it or have it built
Watch the full walkthrough in the video at the top of this post. From there:
- Building payments into your own stack? Start with the M-Pesa integration guide, then the go-live checklist.
- Want it done for you? Talk to our team about a payment form or booking flow for your business.
- Prefer to learn it yourself? M-Pesa integration, start to finish, at Fortune Dev Academy.