What shipped in September 2026

A payment now creates or updates the patient record on its own, so the Patients directory is complete without anyone adding people by hand. Earlier payments have been filled in.

After every acquirer report run the portal retries recent funded reports and marks payments that have settled but not yet been paid out, so what is still on its way is visible.

The Xero backfill now reads every paid payment and every marker rather than only the first page, so older payments no longer get missed.

Medipay Limited's Terms and Conditions, Platform, Terminal and Partner schedules are at portal.medipayuk.co.uk/terms, and the Privacy Policy names the entity, the sub-processors and the support contact.

A demo of the real portal, signed in as a demo practice, runs on medipayuk.co.uk. Every screen works, nothing is charged and nothing is sent. Sales can send a prospect straight to a screen with medipayuk.co.uk/?demo=terminal.

The acquirer fee and net amount are shown where they are real, on the payout, not estimated per payment in the payment drawer.

Phone payments need the gateway set up for mail order and telephone order. The virtual terminal checks that before it shows the card fields, and the practice is told if the setting is missing rather than a patient being sent a bank challenge on a clinic screen.

For practices with their own systems, Medipay can deliver the gateway's payment events as a signed webhook, so a refund or a chargeback raised at the acquirer reaches your software without polling.

The banner that appeared when a pay link for the same amount was open got in the way more than it helped and has been removed. Duplicate-charge protection is unchanged.

A payment imported from the acquirer's report can no longer be marked refunded in the portal without the refund actually being sent, and a refund from the acquirer lands on the sale it reverses.

When a card is refused before authorisation, the terminal and the payment's attempts drawer say what the gateway objected to and what reception can do, instead of a bare code.

The quick-action tiles on the home page no longer clip their text on narrower screens.

The acquirer's daily authorisation records are linked to your payments and shown alongside them, so a decline the issuer made is visible with its reason.

Card logos and expiry, columns you can switch on or off, decline reasons under the status, and a layout that fits the screen. First run with the HQ pilot, now everywhere.

Amount, reference and patient name carry an asterisk, and the charge button stays off until the patient's name is filled in, so no phone payment goes through without a name on it.

Google Pay can be turned on per practice, on top of the wallets setting, once the acquirer has registered the practice for it.

The Today by channel table on the home page no longer runs past the edge of its card.

Money in flight with a chase button, a needs-attention list, payouts, today by channel, what is due today, card machines, who on the team took what today, and seven-day bars. Blocks can be reordered and switched off per practice.

Amounts typed and then abandoned in the virtual terminal no longer linger as active payments, and the patient name is enforced on the server as well as on the screen.

The Pair and Re-pair controls on the Terminals page are visible to every role, and each practice can set a default machine.

Upload a bank statement and match each acquirer payout to the credit that actually landed, under Reporting.

A declined row in Payments shows the reason under the status chip, in the words the card machine or gateway used.

The weekly email carries the home page's money in flight, due and paid out figures, so the week's position is in the inbox.

A pay link created through the API can carry a return address, so a patient who pays from your booking page is taken back to it afterwards.

Receipt on a payment downloads the PDF receipt, the same one the patient was emailed.

A decline on the card machine shows as declined rather than cancelled, and payment requests that stalled on a machine are closed for every clinic.

Every cancelled payment carries the reason it was cancelled: who cancelled a link, a card machine decline or time-out in the machine's own words, a payment request that never reached the terminal, or a pre-authorisation released. It shows under the status in Payments, in the payment detail, in the CSV export and in the API. Older cancellations have been filled in where the record allowed.

Payments started from the portal, the Card machine page or an integration such as Salesforce now print the usual merchant and customer receipts on the terminal, exactly like a payment keyed on the machine. The emailed receipt still goes out as well. Connectors on 1.8 or later pick this up automatically.

The Terminals page now always offers Set up this computer, so each reception or consulting-room PC can run its own connector. Connectors are named after their computer, each card machine is paired from one of them, and the portal sends that machine's payments to that computer only. If the computer paired with a machine is asleep, the portal says which one, rather than a generic offline message.

Once the practice connector is installed on a computer, it stays current on its own: when Medipay ships a new version, every running connector picks it up within a minute, verifies it, and switches over without stopping, so nobody has to run the install command again. The Terminals page shows which version is running.

Every settlement-feed import, scheduled or uploaded by Medipay, now re-checks the rows it just created against payments taken through Medipay and removes any duplicate before it can appear in Payments or reach your accounting software. A daily check also watches every clinic on the feed. You should never see a payment twice; if you do, tell us and we will see exactly which import let it through.

Where the settlement feed had already created a second Online (ONL) row for a payment taken through a Medipay pay link or the virtual terminal, Medipay operations can now list those pairs and remove the duplicate row, leaving the original payment untouched. New duplicates stopped on 3 September.

When you reinstall the practice connector on a new computer and the old one is retired, the machines it had paired are now marked as needing pairing again, and the Terminals page asks for it. Sending to an unpaired machine, from the portal or the API, is refused straight away with a clear message instead of failing at the machine.

When the practice connector shows Offline, the Terminals page now offers Reinstall on this computer. It detects whether you are on a Mac or Windows, gives you the one-line command for that computer, and retires the previous connector so an old laptop cannot pick up payments if it comes back. The card turns green on its own once the new connector is running; then press Pair on each machine, since pairings belong to the old computer.

Every team member now has their own permanent 'pay us' link (Pay links → Copy my payment link). Paste it into your email signature or invoice emails; the patient opens it, enters their name and reference, and chooses the amount. Payments made through your link are recorded as taken by you, so the payments list and exports show who actually sent it. The clinic's older shared link keeps working and is credited to the workspace owner.

A payment taken through a Medipay pay link or the virtual terminal could show up a second time, as an Online row with an ONL reference, once the acquirer's settlement file arrived. The feed now recognises payments Medipay took itself by amount, card and time, so each payment appears once. Payments taken outside Medipay still arrive from the feed as before.