How ArayaThrust Works

Who the platform serves, how a facility becomes a paying subscriber, and why entitlement is never decided in the browser.

Platform overview

ArayaThrust is a cloud clinic management platform for Nigerian healthcare facilities. It is sold as a subscription in four tiers, billed in naira, and priced on facility size rather than patient volume — so a busy month does not produce a larger invoice.

Who it is for

Clinics, hospitals and multi-branch chains in Nigeria, run day to day by administrators, doctors and chief medical directors.

The problem it addresses

Paper and fragmented systems make records hard to retrieve, claims slow to reconcile, and compliance hard to evidence.

How it is bought

A 30-day trial, then a self-serve subscription with a one-time setup fee. Chain deployments are quoted individually.

How the platform operates

This is the subscriber lifecycle as implemented. Each stage is a real step in the deployed system, not an illustration.

  1. Stage 1: Facility signs up

    A clinic administrator, doctor or CMD provides their details and the facility name. The enquiry reaches the ArayaThrust team at the same time.

  2. Stage 2: Email is verified

    A six-digit code, valid for 10 minutes, confirms the address can receive mail — it is where the receipt and the account link will be sent.

  3. Stage 3: Payment is taken

    Checkout totals the plan, the one-time setup fee and 7.5% VAT, then hands off to Paystack for card, bank transfer, USSD or QR.

  4. Stage 4: The charge is confirmed server-side

    Paystack signs a charge event to our webhook. The signature is verified, then the charge is re-confirmed directly with Paystack. Only now does the subscription count as paid.

  5. Stage 5: A receipt is issued

    An itemised receipt is emailed, breaking out plan, setup fee, any annual discount and VAT, alongside the payment reference.

  6. Stage 6: The account is handed to the portal

    A single-use token is minted and emailed as a 'create your account' link. The portal exchanges it server-side for the verified email and the purchased plan.

Why entitlement never comes from the browser

A browser can be made to say anything. If the page that opens the payment window were also the thing that decided the payment had succeeded, a subscription could be granted by editing a variable in developer tools. So the browser’s report is treated as a hint and nothing more.

What the browser does

  • Opens the payment window with a public key.
  • Generates a reference for the attempt.
  • Asks the server whether that reference is confirmed yet.

What only the server does

  • Verifies the signature on the charge event.
  • Re-confirms the charge with the payment provider.
  • Checks the amount paid against the published price.
  • Mints the account token and decides the plan it carries.

Core capabilities

Subscription billing in naira

Purpose
Let a facility buy and renew without leaving the site.
How it works
Four tiers with monthly or annual cycles, a 1x–3x setup fee and 7.5% VAT, itemised before payment and again on the receipt.
Example
A 40-bed clinic subscribes to Professional annually and pays a 2x setup fee in one transaction.

Verified payment confirmation

Purpose
Make sure a subscription is active only when money moved.
How it works
A signed webhook, re-confirmed against the provider, claimed once per reference so a retry cannot duplicate a receipt.
Example
A bank transfer settles after the customer closes the tab; the receipt and account link still arrive.

Secure account handoff

Purpose
Get a paying customer into the portal with the right plan, without trusting the browser.
How it works
A single-use, time-limited opaque token, exchanged server-to-server for the verified email and plan.
Example
The customer clicks 'Create your account' and lands in the portal already on Enterprise.

Clinical modulesPlanned

Records and SOAP notes, pharmacy, laboratory and LIMS, HMO interconnectivity and multi-branch management are what the tiers entitle you to. They are described on the Features pages as product capability, and are deliberately not written up here as working functionality.

Keeping this page honest

Everything above describes behaviour implemented in the deployed system. Where a capability is sold but not yet built, it is labelled Planned rather than described in the present tense, so this page can be used to evaluate what is actually callable today.