Retail Extensions · App · checked 2026-10-24
Third-party payer lets an insurer, or anyone else, pay part of a sale. The customer pays only their share at the till. The retailer claims the rest afterwards. It is coming and is not in the App library yet. This page says what it will do, which markets ask for it and what it waits on. It is part of Pharmacy on iVendNext.
What it does
In many markets a pharmacy cannot sell to most patients without their insurer. The insurer pays part of the sale and the patient pays the rest. The same shape serves an optical plan, and a company that pays for what its staff buy.
This app is one payer service for any third party that pays part of a sale. You fill in the payers, the plans, the formularies and the members. The app then does four jobs:
- At the till, it answers what the cover pays before the customer pays.
- It makes a claim from each sale that iVendNext POS books.
- It puts the claims in a file for the payer.
- It follows each claim to payment.
The payer's share is booked as money the payer owes you. It is never booked as money already taken. The receipt shows the claim reference and the split. A return gives the payer's share back to the payer.
The first data set is one generic insurer. It is a sample, not a real insurer. Your partner replaces it with each real payer's terms, and writes each payer's own claim link. A second data set, a company that pays 70% of what its staff buy, loads and answers with no new code.
Which markets ask for it
It is meant for Kenya, Saudi Arabia, the UAE and Ghana, where many patients are insured. Your partner writes each payer's own claim link against the same app. The links named are SHA, NPHIES, eClaimLink, Shafafiya and NHIA.
How a sale is split
Each plan has rules, and every rule is data you set.
| Rule | What it does |
|---|---|
| Co-pay percent | The customer's share of the covered amount inside the limit. |
| Invoice upper limit | The most the payer covers in one sale. The customer pays the rest of the covered amount. Zero means no limit. |
| Maximum co-pay | The co-pay never goes above it. Zero means no maximum. The excess over the limit, and the extra-item pay, are not co-pay. |
| Extra-item pay | A fixed amount for each stock unit that the customer always pays in full, before anything else. It is a formulary row. |
| The limit is compared with the amount | Before or after the sale's discount. |
| The co-pay percent is taken | Before or after the discount. Before means the payer keeps the whole discount. After means the customer shares it. |
| Returned whole or not at all | A sale on the plan is returned whole, or not at all. |
| Most units on a sale | Units past this number are the customer's. It is a formulary row. |
| Covers | Formulary items only, or every item. A line the plan does not cover is the customer's. |
| Price list | When you set one, a sale on the plan is priced on it. An item the list does not carry, or carries at zero, cannot be sold on the plan. |
| Your own promotions apply | When this is off, a sale on the plan is priced with your promotions and coupons switched off. A retail promotion is then not stacked on the payer's list. |
The payer's share plus the customer's share always equals the sale, to the cent. The payer's share is spread over the covered lines in proportion. The sale's prices are never changed by the app. Your own pricing, such as the plan's price list, prices the sale. These rules only split it.
Claims
- iVendNext POS books a sale with its payer details: the claim reference, the cover, each line's two shares and the prescription details it sent.
- Press Build claims on the Payer list. The app makes one claim for each booked sale, named by its claim reference, so a sale is never claimed twice. A return reduces its claim's lines by what it gave back to the payer, once.
- A claim that lacks what its payer needs gets the status Incomplete. A payer may ask for the member number, the card serial, the prescription, each line's GTIN, and the dose and frequency. The claims clerk fills in the claim on the Desk and presses Mark ready. The app refuses while anything is still missing. Nobody types a claim's status. The claims file, Match, Mark ready and Settle as it stands move it.
- Press Make the claims file on a Payer. Every Ready claim of that payer goes into one claim batch, a file with one row for each claim line. Send this file to the payer. Each claim becomes Submitted, or Resubmitted when it was corrected after a rejection.
- Enter the payer's remittance line by line: the claim, the amount paid, the amount rejected and the payer's reason. Press Match. The app adds up every line of one claim and compares the total with what the claim is still owed. A payer that pays a claim line by line, or in parts over several remittances, is followed to the cent. The claim becomes Paid, Short paid or Rejected. A reference that is not yours, or that belongs to another payer's claim, shows as Unmatched. The money itself is your own payment from the payer's customer record, set against what the till booked.
- Correct a rejected claim and press Mark ready again. The next file sends it as Resubmitted. Or bill the claim to the customer, with a button that arrives with the door.
- Press Settle as it stands to close a short-paid claim and leave the shortfall on the payer's account.
The app adds four reports: claims, rejected and short-paid claims, incomplete claims, and remittances. It adds two charts: the payer's share by month and claims by status.
What it waits on
The payer's share must be owed by the payer. Until a payer pays, it is money the payer owes you, not money you took. An app cannot book that alone, so iVendNext POS needs a general part for it, called the payer door. The door is not in iVendNext POS yet.
The app arrives with the next iVendNext POS update that carries the door. The claims clerk's button Bill to the customer arrives with the door. Until then, nothing is sold on a payer. This page gives no date.
What leaves your store
The service reads iVendNext with its integration user's key and answers the payer door. It keeps nothing between calls.
Members and claims are health data for a pharmacy, so run the service in your own region. The claims file goes to the payer, which is the point of a claim. Send it nowhere else. A member number reaches the till only masked to its last four characters.
Limits
- Nothing is sold on a payer until the payer door is in iVendNext POS.
- The generic insurer is a sample. Replace it with each real payer's terms.
- The sale's own discount applies to the excess over the limit. The app does not add a surcharge. If you want the customer to pay the excess without the discount, set that in your own pricing.
- The till prices an item that is missing from the sale's price list, or at zero on it, from the store's list, and says nothing. A line's price therefore proves nothing. The app reads your Item Prices on the plan's list.
- Do not make a plan's price list a customer group's default. It would price every sale for that member, insured or not. The payer door switches the sale to the plan's list when the cashier picks a cover.
- Pharmacy counter rules keeps a prescription's directions as free text. The claims clerk types the dose and frequency where a payer asks for them. Abu Dhabi's Shafafiya asks for them on every line.
- The tick Barred from sales a third party pays is on the customer. Anyone who can edit a customer can clear it. To stop a cover for certain, the claims clerk also switches the customer's member off.
- Only the claims clerk role and the service's user read members and claims. A till role never does.