Online payments are HERE!

LOVE LOVE LOVE!!!

Absolutely love this! PLUS THE TELEHEALTH! Round of applause of fast tracking this development. Very much appreciated over here in Northern Ireland, UK. We have had to close all face to face appointments and the combination of telehealth and online payments is a life saver.

My only question with regards to telehealth: How much is it costing at current? And how much will it cost in the future? Up to this point I have been planning on using Physiapp/physitrack to provide telehealth at a cost of £25/ month. I’m wondering how much your service will cost in the long run?

Many thanks from a satisfied customer.

Tim

Looking forward to being able to take payment in CLiniko. Many of our clients receive a rebate back, but this claim can only be made after the session. I doubt many will want to be out of pocket while waiting for their appointment, potentially for weeks. A great feature, but I really look forward to the rest coming soon.

1 Like

This is brilliant! So thrilled it’s coming along with the telehealth option as well. Can’t wait to see how that rolls out.

Two things that would be super helpful:

If people tick that they are paying onsite, the form still requires them to fill in all their card and billing details. Is it possible to toggle that requirement off if they tick ‘pay onsite’ radio button?

Also - can it be made mandatory for some booking types and not others as a simpler workaround? I want people to use this function for telehealth as I won’t be seeing them but it’s less an issue for other appointment types - so the form would be quite tedious for an in person appointment when they are paying here (faster to do that using the card reader than the form!)

Thank you again so much!

Tracy

1 Like

Telehealth under Medicare we can’t accept payments, it has to be bulk billed. This new feature is great for my privately funded (health insurance) clients though they are significantly less than Medicare clients.

Please bring in a “Pay now” link to send to clients, so they can pay using stripe, from a link (SMS or emailed). This will enable touch free payment at the end of sessions or for non face to face consults. I know Medipass exists but that is cumbersome and literally made me feel ill after numerous issues using it. Please now that you are integrated with Stripe, taking online payments at booking, work on a simple payment solution where a “Pay now” link can be used, the practitioner can then use flexibly to their preferences. Eg pay at beginning, during, or after sessions.

6 Likes

One of the additional features we’re looking to include is a way to include a link with the invoice email to let patients pay that directly. Great suggestion @ipsych!

7 Likes

@TracyH

I’m not sure about the idea of storing payment details - though Stripe would allow that. We’ll add that to the conversation

@advancephysio A little off-topic, but we haven’t yet set a price on Telehealth yet. We’re going to be trying to make it as competitive as we possibly can though.

@RetrainHealth Not at the moment. As we don’t charge those fees (Stripe does) I’m not so sure that’s feasible directly.
Fair suggestion on customising per appointment type though!

1 Like

@jim I didn’t quite mean that - I mean, if someone is not paying online, ideally they shouldn’t have to fill in their payment and billing information at all. It makes the process of booking longer and more cumbersome.

No need to save their payment details - but can we have the form fields ‘optional’ (rather than mandatory) if people are not paying online?

(Ie right now I want it on for telehealth as that’s my only live appointment type - however, it can’t be offered as an option in the future for other appointment types if it requires people to wade through the whole billing process when they intend to plonk down cash at the appointment).

Thank you!

Makes sense @TracyH!

We have that setting across the whole bookings page, to make payments required or optional, but it would definitely be better to have that set per appointment type. That way you could require payment for certain services, while leaving it optional for others. Good suggestion!

3 Likes

I tried the On-line payment along with Tele-Health this weekend. I have requests for both but in context of this thread on On-Line payment I have 2 requests/features.

  1. I have to enable ‘Show Prices’ in Online booking settings which effects presentation of prices for all services. I prefer not to do that. Can you not just show the prices for services where on-line payment is turned on? or present it later in the payment screen.
  2. Is it possible you can add the ‘Appointment Type’ and ‘Practitioner’ into the Description field sent to Stripe? This seems possible in the API. Not having this information hinders tracking.

@joel can you remove the Billing Address details please? Will make the form shorter and reduce double entry for client.

Hi, thanks for the great new feature.

Is there any plans to link the online payment invoice amount to the patient’s individual concession type?

Say I’ve got a customer set up with a concession that gives them 20% off the normal fees.
With the current online payment system, this person would be asked to pay more than they usually would.
I use a few different concession types and it wouldn’t be practical to set up billable items for these types of appointments.

I also noticed that you can no longer turn off the price being displayed on the booking page when you have the online payments enabled. This again isn’t ideal when I have people set up with different concessions, as these prices are not what they’ll be charged.

Thanks!

1 Like

Hi Cliniko,

I was wondering whenever a patient wants to book a second appointment in via the online booking they will have to re-enter all their details again - is there any way around this?

If not, is a patient portal/ mobile app a possible feature request? Somewhere they can log on and their details would be saved no matter the device/ internet browser.

Tim

We had still trialling this. At the moment we don’t have a HTTPS site. I did not thing this world be a problem because Cliniko On-Line booking is HTTPS and of course Stripe is secure within it. However the client got a security alert. The client was a tech and here is what he said.

"While making a booking through the HealthSpace website, I noted that the mobile browser I was using was highlighting the fact that there wasn’t a secure connection. As both PII and credit card information needed to be submitted, this got me curious, as I know sending CC information over insecure links is a PCI DSS fail. I ended up doing a bit of investigation to understand what is going on here.

What I identified was that the HealthSpace website is served over an insecure link, but utilises an iframe to wrap the Cliniko pages. Effectively this is an insecure page wrapping a secure page. This is a bad idea for a number of reasons:

  1. This fails the current (3.2.1) Payment Card Industry (PCI) Data Security Standard (DSS) requirement 4.1, which states “HTTPS” appears as the browser Universal Record Locator (URL) protocol . See page 48 ofhttps://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf for further details of PCI DSS requirements and guidance.
  2. The lack of integrity for the parent HTTP page means that it can be manipulated, and the change in content cannot be detected by the user. The user has no way of knowing that they’ve been directed to cliniko.com or steal-your-credit-card-details.com.
  3. It makes injection of JavaScript attacks much easier, as these would take place against the parent HTTP page, not the Cliniko page. This is pretty much enabling Cross Frame Scripting. See https://owasp.org/www-community/attacks/Cross_Frame_Scripting for further details. Attacks of this nature have already been seen in the wild.
  4. This is training users to ignore the “padlock” – users are often told to look for the padlock before submitting any sensitive information
  5. Chrome on mobiles will warn users that the page is not secure, and this may prevent users from submitting this information. See attached screenshots.

Hi Robert,

You could directly link to online bookings, which is secure, rather than embedding it in your website, until you have setup HTTPS on your website.

Yes. I did revisit this and i appreciate the option. If this is genuinely a fault of us not having https i think i will fix that. “Its not you it me!”

Re TracyH’s suggestion, I am aware that in Power Diary, which uses Stripe, you can vault client payment details and use them to put through payment after the session. This feature would be ideal for my practice. Many clients book weeks in advance, and will only get a Medicare or Private health rebate after the actual session. They need to pay full fee, and will generally not want to be out of pocket a large amount for very long. The alternative at present for Telehealth consults is that we chase them for payment after the session and this is time consuming and problematic. The link on an invoice still relies on them paying. The Stripe vault function would be great, as it would allow contactless transactions in the clinic in the future, and help us get Telehealth payments at the time of the consult.

3 Likes

Much agreed! We need a vault feature for sure

2 Likes

Cliniko with its OPEN API

can allow you use an card processor to be used. As long as your card provider has an open API, which it more likely will, all you need is a connector to pass the information between the 2 to be developed. and we can help with this… and your cheaper rates…

Essentially, Stripe aint cheap… so save money on your transactions.

Shane
Shane@lucrosolutions.co.uk

I was going to suggest the same thing. This makes it super easy for the clients!

Do you have an update on when this feature is coming?

I send all of my invoices from Xero at the moment as I have the stripe link setup there, but the clunky/non-existent Xero integration for third party biller details makes me want to smash my computer on a daily basis. Please fix it as the integration actually makes it worse than doing it manually.