How billing works
Your plan includes a number of transactions each month. A transaction covers one request and the number of successful system deliveries included in your plan. The examples below use a plan that includes 5 systems per transaction. Here is exactly how transactions are counted, and what else is on your monthly invoice.
Larger plans include more systems per transaction; the plans page shows each one.
Example 1 One message, one system
A clinic’s system registers a patient. Segora receives the message, transforms it, and delivers it to the client registry. The registry’s answer goes back to the clinic.
Example 2 A chain with an orchestration
The same message goes to the client registry, which passes it on to the shared health record (a chain). Alongside, a copy goes to the reporting system (an orchestration: it runs, but does not change the answer the clinic gets). Segora made three deliveries, but one request came in, and it stayed within the 5 systems a transaction includes: one transaction.
Examples 3, 4 and 5 assume your plan includes 5 systems per transaction. Every successful delivery counts towards that number: the one target, the systems chained after it, and orchestrations. Each plan sets its own number; the plans page shows yours.
Example 3 Five systems: a chain with orchestrations
The clinic’s message goes to its one target, the client registry, which passes it on to the shared health record (a chain). The shared health record’s answer is the one that goes back to the clinic. Alongside, copies go to the immunisation registry, reporting and the lab as orchestrations. That is five systems in total, counting the target, the chain and the orchestrations, exactly what the plan includes: one transaction.
Example 4 Six systems: one more orchestration
The same workflow with one more orchestration, to the HIV programme register. Six systems in total: the first five deliveries are the first transaction, and the sixth starts a second block of five, so this request is two transactions. Up to ten systems would stay at two; an 11th would start a third.
Example 5 A Segora mediator after the target
The clinic sends its message to the interoperability layer, which is the request’s primary target. The interoperability layer returns its response to the clinic.
A Segora mediator also receives the interoperability layer’s response as part of the workflow. It checks the response against configured rules, transforms it and delivers it to the immunisation registry.
The two successful system deliveries use one transaction, within the 5 a transaction includes. The mediator completes its processing and adds one more transaction. The request therefore uses two transactions in total.
If the mediator stops because its rules are not met or a step fails, it does not add a transaction.
Requests and transactions are different numbers
A request is a message a source sends in. Deliveries are what Segora sends on to your systems. Transactions are what is billed: one for each request with at least one successful delivery, plus one for each further 5 successful deliveries, plus one for each Segora mediator that completes. A request whose deliveries all fail is not charged. On the Ecosystem page you see requests on your sources, deliveries on your targets, and the billable transactions.
| Requests | Deliveries | Transactions billed | |
|---|---|---|---|
| Example 1: one system | 1 | 1 | 1 |
| Example 2: chain and orchestration | 1 | 3 | 1 |
| Example 3: target, chain and orchestrations (5) | 1 | 5 | 1 |
| Example 4: one more orchestration (6) | 1 | 6 | 2 |
| Example 5: a Segora mediator | 1 | 2 | 2 |
| 1,000 messages a day, as in example 2, for 30 days | 30,000 | 90,000 | 30,000 |
What is never counted
- Deliveries within the 5 systems a transaction includes, whether they are the target, chained systems or orchestrations. They are part of the request’s one transaction.
- Responses returned to the source. The reply the calling system receives is part of its request.
- Failed deliveries. A delivery that fails is not counted towards the 5 systems a transaction includes. Successful deliveries are still counted, even if another delivery in the same request fails. A request whose deliveries all fail is not charged. Failed requests and deliveries remain visible on your Activity page.
- Testing a mapping in the Mapper’s Inspect window (Run transform and Generate example). Only calls from your systems through the API are counted.
- Validating before delivery. When a FHIR® target checks a message first, that check is part of its delivery.
- Translating an answer back into the source’s own structure (the reverse transform for a read).
- Steps skipped because their conditions were not met, or because their mapping could not transform the message, and a Segora mediator that stopped.
- AI suggestions. You use your own AI key.
- The demo. Nothing is charged while your organization uses the demo.
Testing a workflow is different: it really sends to your systems, so it counts like any other request.
Reading or removing a record
A workflow can also pass on a request to read (GET) or remove (DELETE) a record. That is one transaction. Its answer back is not counted, and orchestrations do not run for these.
Segora mediators
A Segora mediator performs additional processing within the workflow: it checks rules and can transform the message at each step. Each mediator that completes adds one transaction to the request, however many steps it contains; a mediator inside another mediator counts as one more. A mediator that stops, because a step’s rules were not met or a step failed, is not counted. The systems its steps deliver to count towards the request’s systems as usual.
Scheduled sources
A source can also fetch from a system on a schedule. Each record it fetches is handled exactly like a message sent in, so each one is a transaction, counted the same way. A fetch that finds nothing new, or that fails, is not counted.
Transforming only
Your system can also call a mapping directly through the API, just to transform a message, with no system to deliver to; the transformed message comes back as the answer. That is one transaction. Running the same mapping yourself in the Mapper’s Inspect window is free.
Your monthly allowance
- Each plan includes a number of transactions per calendar month, and how many systems each one is delivered to (the plans page shows both). Unused transactions don’t carry over: every month starts with the full allowance.
- Your administrators are emailed, and every page shows a notice, at 80%, 90% and 100% of the allowance.
- On a paid plan, when the allowance is used up, messages keep flowing for 14 days, each further transaction billed at your plan’s extra rate (shown with each plan on the plans page). That gives you time to move to a larger plan. If you haven’t by then, new messages pause until you do or until the next month starts (a new month always brings a new allowance). You can always sign in and work.
- The Free plan has no fee, no onboarding charge and no invoice. It has no extra transactions either: once its transactions for the month are used, new messages wait until the next month, or until you move to a paid plan. Once an organization is on a paid plan, it can't go back to the Free plan.
See it for yourself
- Organization › Plan shows how much of this month’s allowance is used.
- Organization › Usage and bills shows the month’s statement, line by line.
- Organization › Activity lists each request and its deliveries, and whether each succeeded.
- Ecosystem shows requests and deliveries per system as they happen.
Prices per plan are on the plans page. The Terms of Service are what applies.
What is on your monthly invoice
- Your plan’s monthly fee. If you change plan during a month, each plan is charged for the days you were on it.
- Extra transactions, beyond your plan’s allowance, at your plan’s extra rate.
- Extra projects and packs of mappings beyond what your plan includes, per month, while you have them. Before one is created, Segora shows its price and an administrator must accept the charge on screen. Nothing beyond your plan is billed without that acceptance, and until it is accepted it does not exchange data.
- Onboarding, once, in the month your organization is approved. It is not charged when you prepay a year, or on plans without an onboarding fee.
- Priority support, if you add it to a plan that does not include it.
- Paying a year in advance. The plan fee for 12 months, less the annual discount (and priority support for 12 months, if you chose it), is invoiced at once, when your organization is approved or when you choose it on the Plan page. For those 12 months the plan fee and the prices of extra transactions, projects and mapping packs stay as they were; what you use beyond the plan is invoiced monthly at those prices. The year renews at the prices current then, invoiced 14 days before it ends, unless you switch to monthly billing. Moving to a larger plan during the year: the difference for the rest of the year is invoiced straight away. Moving to a smaller plan starts when the year ends.
Non-profit organizations whose registration we have verified pay the NGO price; others pay the standard price. The plans page shows both, and every amount above.
When and how you pay
- Invoiced monthly. Each month’s invoice is issued at the end of the month and emailed to your organization’s billing email and administrators. During the month, Organization › Usage and bills shows the charges so far.
- One currency. Organizations in South Africa pay in rand; elsewhere in US dollars. Each currency has its own fixed prices: nothing is converted with an exchange rate.
- One payment reference. Your organization’s payment reference is the same on every invoice, so you can save it once with the beneficiary.
- Due as stated on the invoice, by bank transfer, using that reference.
- VAT is added only where it applies, and is then shown on the invoice.
- A monthly limit can be agreed for your organization, to protect it from unexpected cost.