Straight answers, no detours.

MTN Mobile Money and Orange Money, the two wallets used in Cameroon. Your customer has nothing to choose: we recognise their operator from the prefix of their number and send the request to the right network. Other payment methods may be added later, but we would rather do these two properly before announcing any others.

A payment must be between 100 FCFA and 1,000,000 FCFA. Those limits are the platform's; your operator also applies its own ceilings, which depend on the level of your customer's Mobile Money account. A payment refused for exceeding a ceiling comes back with an explicit message.

The payment request stays on their phone for a while, then expires at the operator's end. The payment then fails with a reason along the lines of “code not entered in time”, and your customer can start another attempt from the same page without you having to recreate an order. No commission is due on a transaction that does not go through.

A payment page stays usable for 30 minutes after it is created. After that the payment moves to “expired” and the link no longer allows payment: you have to create a new one. It is a protection against links left lying around in a conversation that someone reopens three weeks later.

This happens when the customer paid to the merchant code from their USSD menu instead of confirming the request sent by the platform. In that case they declare their transaction reference on the payment page, and the operation goes into a confirmation queue: it is checked, then approved or refused. You see these cases in your dashboard, and the payment only moves to “succeeded” once it has been checked.

The mode of a call comes from the key used, never from a parameter: an “sk_test_” key cannot move real money, an “sk_live_” key cannot create a fake payment. Both sets of keys live side by side on the same account, and your test transactions stay separate from your real ones in the dashboard.

By querying the API with your secret key: GET /api/v1/payments/{id}. That response is the one that counts. Never release an order on the strength of the browser redirect alone, nor on the contents of a webhook alone: treat the webhook as a signal telling you “go and check”, then check.

Start with the notification log in your dashboard: it shows the address called, the HTTP code returned and the response received. A notification that is not acknowledged is retried up to 8 times, with lengthening delays, and you can replay it manually. The most frequent causes are an HTTP address that cannot be reached from outside, an expired certificate, bot protection, or a CSRF token check blocking the request.

Every call carries the X-WalleoPay-Signature header, which contains a timestamp and an HMAC signature computed over “timestamp.body” with your secret. Recompute it on your side, compare it with a constant-time comparison function, and reject calls whose timestamp is too old. A notification whose signature does not match must be ignored, without exception.

Not if you send an idempotency key when creating the payment. The same call replayed then returns the original payment instead of creating a second one. It is one header line to add, and it saves you the costliest class of bug in a checkout flow.

Test mode provides dedicated numbers whose outcome is known in advance: success, insufficient balance, refusal by the customer, no response. You can therefore check what your shop displays in each situation without waiting for a real customer to hit the problem. The list is in the documentation.