Sign in

Commerce & campaigns

Phase 3 gives merchants hosted, no-code selling surfaces — storefronts, event tickets, recurring subscriptions, and crowdfunding campaigns — managed entirely from the dashboard. There are no new API resources: your integration surface is the webhook events these flows emit, documented below and in Webhooks.

The hosted surfaces

Surface Public URL Set up in
Storefront /store/<slug> Dashboard → Commerce → Storefront
Event ticket /t/<signed_token> (QR on every ticket) Storefront → event listing → Manage event
Payment link (one-off or recurring) /pay/<slug> Dashboard → Payment Links
Campaign /c/<slug> (+ invite & member links) Dashboard → Commerce → Campaigns

All buyer/contributor money flows through the same collection pipeline as API charges — compliance screening, fees, and the ledger apply identically, and amounts are integer minor units everywhere.

Events you can subscribe to

Register endpoints under Dashboard → Developers; deliveries use the same signed envelope and retry schedule as Phase 1 events.

  • Orders — order.paid, order.fulfilled, order.cancelled
  • Tickets — ticket.issued (one event per order, all references included), ticket.checked_in
  • Subscriptions — subscription.created, subscription.charge.success, subscription.charge.failed (carries cycle, attempt, and final: true when retries are exhausted), subscription.cancelled
  • Campaigns — campaign.contribution.received (includes the running balance), campaign.disbursed

Sample payloads live in Webhooks.

Recurring billing behaviour

First payments happen on the hosted subscribe page. Cards tokenize automatically (recurring cycles charge silently); mobile-money subscribers either approve each cycle on their phone (default) or opt into a silent-debit mandate where their network supports it. Failed cycles retry on a backoff (+1 day, +2 days, +3 days) with dunning notices to the subscriber; recovery reactivates the subscription, exhaustion cancels it — each step emits the events above so your systems can mirror the state.

Testing in the sandbox

Every path — including retry → recovery and dunning → cancellation — is reproducible with the sandbox magic values, e.g. the tok_sim_retry card token or the 0240000003 mandate MSISDN.

Previous VAS catalog