Solutions by business

The API is the same for everyone. What changes from one business to the next is which products you assemble and in which order you build them. A shop needs a checkout and a webhook. A marketplace needs the money to reach someone other than itself. A payroll platform barely collects at all.

Each path below lists its products in build order, and says plainly what it requires: the plan it opens on, and whether you can build it against the sandbox or only in production.

Which path is yours

Answer one question, where does the money end up.

Paths overlap, and that is normal. A marketplace still sells and still refunds, so it reads the e-commerce path first and adds subaccounts on top.

What every path starts with

Payments, the hosted checkout page, refunds, customers, webhooks and events are core. No plan gates them, and they behave identically in the sandbox and in production. Whatever you are building, this is the ground you stand on, and it is the part you should get working before anything else.

E-commerce and online sales

You sell products or services, and each customer pays once.

Before writing any code, check what your shop already runs on. If it is WordPress, the official plugin covers WooCommerce, GiveWP, Easy Digital Downloads, Tutor LMS, MemberPress and Gravity Forms, with a [wajub_pay] shortcode for everything else. You paste your keys and you are done, there is no integration to maintain.

If you are building the shop yourself, three steps are enough. You create the payment when the cart is validated, you send the customer to the authorization_url that comes back, and you fulfil the order when the payment.succeeded webhook arrives. Never fulfil on the redirect alone, a customer who closes the tab still pays.

Refunds come last on purpose. You need orders flowing before you have anything to refund, and the refund endpoint needs a payment id you will only have once step one works.

Everything here runs on Pay as you go, in the sandbox and in production. The one exception is Payment Links, which is production only and capped at 25 links on the free plan before it becomes unlimited on Growth.

Marketplace and platform

You connect sellers and buyers, and the money has to reach the seller rather than stopping at you.

That is what Sync does. Each seller becomes a subaccount with its own capabilities, its own pricing and its own transaction history. You then act on a seller's behalf by adding one header to a call you already know how to make, X-Sync: acc_…, so there is no second API to learn. Onboard the sellers before you route a single payment through them, since a subaccount has to be accepted and active before it can transact.

Payouts close the loop. Beneficiaries let you register a seller's wallet once instead of re-sending the number and the operator on every transfer.

Sync is a Scale feature: the Sync pages of the Dashboard, where you create and manage your connections, open from that plan. It does work in the sandbox, but a subaccount belongs to one environment: calling a sandbox subaccount with a production key, or the reverse, returns 404 Sync account not found., since each environment only sees its own subaccounts. Transfers and beneficiaries are available on every plan.

Mass payouts and gig economy

You distribute funds: salaries, driver earnings, commissions, prize money.

POST /transfers/batch takes up to 500 payouts in one call. Its Idempotency-Key header is required and each line carries its own reference, so a batch that half fails is sent again as it is: only the lines that did not go through leave the second time. Each line passes the same checks as a single payout, and one refused recipient does not stop the others.

Registering your recipients as beneficiaries first is what makes that batch short. Each line pays a ben_… identifier instead of repeating the phone number, operator and country, and a payroll run becomes a list of identifiers you already hold.

Watch the balance, not the API response. A transfer is refused when the available balance is short, so a payout run should read the balance before it starts rather than discovering the problem on recipient forty.

Transfers, batches, beneficiaries and balance are on every plan and work in the sandbox through the API. In the Dashboard, the button that creates a transfer by hand is production only.

Subscription and recurring billing

You bill the same customer every cycle.

Recurring billing on Wajub is built on invoices, not on a stored mandate. Mobile Money gives you no way to silently debit a wallet later, so each cycle produces a new invoice with its own payment link, and the customer approves it. You create the first invoice with is_recurring set and a recurring_frequency of daily, weekly, monthly, quarterly or yearly, and Wajub issues the following ones on schedule. Changing the amount or the cycle means updating that invoice, and cancelling it stops the billing.

Reminders are what make the model actually collect. Because every cycle needs a human approval, an unpaid invoice stays unpaid until someone is nudged, so treat the reminder schedule as part of the integration rather than a nicety.

There is no products, prices or coupons resource to model your catalogue against. If you need tiered plans, proration or metered usage, you build that logic on your side on top of the Payments API, and the recurring billing guide walks through it.

Invoicing is available on every plan, capped at 10 invoices on Pay as you go and unlimited from Growth. Recurring generation itself needs Growth or above, and it fails quietly if you drop below it: the parent invoice is kept but no new cycle is issued until the plan is restored. Invoices are production only, so build and test your payment and webhook handling in the sandbox first, then switch the key before you touch invoicing.