# You can take your first African payment this weekend

> For developers and vibe coders: let your AI assistant wire up mobile money with one command, test it in sandbox, and charge a real customer by Sunday.

Published 2026-10-07 by the Ultraner team. Topic: build. Tags: developers, ai, vibe-coding, sandbox.
Canonical: https://ultraner.com/blog/ship-payments-this-weekend-developers-and-vibe-coders

Most side projects in Africa die at the checkout, not at the idea.

You build the thing on a Saturday. It works. Your friends in Dar es Salaam or Nairobi want to pay for it. And then you discover that the payment tutorials you know were written for people whose customers carry credit cards, while yours carry M-Pesa, Airtel Money and Mixx by Yas on a phone that is never more than a metre away. The World Bank's Findex survey has shown for years that across much of sub-Saharan Africa, more adults hold a mobile money account than a card [2]. Your checkout has to start there.

This is the short path, written for two kinds of builder: the developer who reads every line, and the vibe coder who describes the feature to an AI assistant and reviews what comes back. Both end in the same place: a real payment from a real customer, before Monday.

## Saturday morning: let the assistant do the boring part

Open a terminal in your project and run:

```bash
npx ultraner init
```

It looks at your stack, asks what you are building (a shop, a subscription, a marketplace, a donation page), recommends an integration and, if you say yes, writes it into your project. It does not touch anything without asking.

If you work inside Claude, Cursor or another assistant that speaks the Model Context Protocol [1], add the Ultraner MCP server instead and let the assistant call the API itself:

```bash
npx @ultraner/mcp
```

The assistant can then look up which networks are live in a country, check a currency's decimals, and draft the charge call against your sandbox key. The [AI page](/ai) lists the setup for each assistant, and the [agent skills](/ai/skills) give it the house rules (amounts, phone formats, webhooks) so it stops guessing.

One habit worth keeping: read what the assistant writes for money. Not because it is usually wrong, but because the two mistakes that hurt are small and quiet. An amount a hundred times too large. A webhook that trusts whatever arrives.

## Saturday afternoon: one charge, end to end, in sandbox

Get a test key from the dashboard. It starts with `uk_test_` and only works against sandbox paths, so nothing you do today moves real money.

The whole charge is one request. Ultraner reads the country from the phone number and routes to the right rail; you only say which network:

```js
const res = await fetch('https://api.ultraner.com/v0-sandbox/payments/charge', {
  method: 'POST',
  headers: { 'X-API-Key': process.env.ULTRANER_KEY, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    method: 'mobile_money',
    amount: 5000,            // TZS has no cents: 5000 means TZS 5,000
    phone: '255712345678',   // country code first, no plus sign
    provider: 'Airtel',
  }),
});
```

The response says `pending`. That is correct. Mobile money is a conversation with a person: your customer gets a prompt on their phone and approves it with their PIN. The result arrives later, by webhook. Build the webhook before you build the success page, and verify its signature before you believe it. The [developer guide](/blog/first-mobile-money-charge-developer-guide) walks through exactly that in thirty minutes, with every outcome (approved, declined, timed out) testable in sandbox.

Two details save an afternoon of confusion:

- **Amounts are in the smallest unit of the currency.** For KES that is cents. For TZS, UGX, RWF, XOF and XAF there are no cents at all, so the number you send is the number the customer sees. A short table per currency beats remembering.
- **Phone numbers are full international digits.** `0712 345 678` in Tanzania becomes `255712345678`. Normalise once, at input, and never think about it again.

## Sunday: go live

Going live is mostly paperwork, and it is quick:

1. **Verify your business.** Ultraner checks who you are before real money flows, the same as any payment provider. Start it on Saturday so it is done by Sunday.
2. **Swap the key and the path.** `uk_live_` instead of `uk_test_`, `/v0/payments/charge` instead of `/v0-sandbox/payments/charge`. Nothing else in your code changes.
3. **Charge yourself first.** A small real payment from your own phone, then a refund. If both arrive where you expect, you are ready.

The networks your customers use are listed per market on the [payments pages](/payments), with Tanzania and Kenya among fourteen live today. Pricing is on [one page](/pricing), and nothing is charged until money actually moves.

## What to build next, while it is still the weekend

Once one charge works, the rest is composition:

- **A payment link** for the customers who will not open your app. Send it on WhatsApp, get paid on mobile money.
- **Subscriptions** that send a fresh prompt each month, because a mobile money wallet cannot be charged silently the way a saved card can. Design for that and your renewals stay healthy.
- **Cards and PayPal** for the friend in London who wants to pay too, through the same integration.

None of this needs a payments team. It needs one afternoon of care around amounts and webhooks, and an assistant that knows the rules.

The fastest way to learn whether your idea has customers is to ask them for money. Now you can, by Sunday. Start with the [docs](/docs), or just run `npx ultraner init` and see what it offers.

## Sources

[1] Model Context Protocol, Anthropic. https://modelcontextprotocol.io/
[2] The Global Findex Database 2025, World Bank. https://www.worldbank.org/en/publication/globalfindex
[3] State of the Industry Report on Mobile Money, GSMA. https://www.gsma.com/sotir/