Hosted checkout

The hosted checkout runs the entire payment flow at checkout.mediquo.com. You open a URL with the payment details; Mediquo renders the portal, processes the payment, and reports the result. There's nothing to build, theme, or maintain.

This is the integration the Mediquo native apps use inside a WebView, and it works equally well in an <iframe> or a new tab.

There are four routes, depending on how the payment session is created — the same split as the web components:

Charge for an appointment

Send the user to /appointment with the booking details in the URL:

https://checkout.mediquo.com/appointment?api_key=KEY&slot_id=SLOT123&service_id=SVC456#token=USER_TOKEN

Parameters

Parameter names are snake_case.

Charge for an immediate videocall

Send the user to /immediate-videocall with the videocall schedule id. Mediquo creates the Addon Payments session and runs the same portal / polling flow as appointments. Coupons and Stripe do not apply on this route.

https://checkout.mediquo.com/immediate-videocall?api_key=KEY&video_call_schedule_id=VCS123#token=USER_TOKEN

Parameters

api_key, token, locale and env are the same as above. Instead of a slot, this route takes the schedule to pay for:

On success the relayed payload is { videoCallId } — the videocall created by the Addon webhook once payment is confirmed. See <mq-immediate-videocall-checkout> for the matching web component.

Charge for a custom session

When the charge isn't an appointment, create the payment session on your backend first, then send the user to / with the resulting session in the URL:

https://checkout.mediquo.com/?api_key=KEY&session_id=SESS123&payment_url=https%3A%2F%2F…#token=USER_TOKEN

Parameters

api_key, token, locale and env are the same as above. Instead of a slot, this route takes the session your backend created:

These are the same { sessionId, paymentUrl } a provideSession callback returns with the <mq-checkout> component — here you pass them in the URL instead of a callback.

There's no discount_code parameter on this route: the price is fixed when your backend creates the session, so apply any discount there.

Apple Pay (/apple-pay)

For Apple Pay, open the verified domain in Safari or SFSafariViewController (not a normal in-app WKWebView). Create the payment session on your backend first, then:

https://checkout.mediquo.com/apple-pay?api_key=KEY&session_id=SESS123&amount=29.99&currency=EUR&country=ES&label=Consulta#token=USER_TOKEN

Native apps should present Card vs Apple Pay in native UI, then open / (card) or /apple-pay accordingly. See mq-apple-pay-checkout.

The user token

Put the user token in the URL #fragment (#token=...), never the query string. The fragment is never sent to servers, so the token stays out of access logs and the Referer header. A token placed in the query string is ignored and the page reports it as missing.

If a required parameter is missing or invalid, the page shows a plain-text message listing what's wrong and does not start the payment.

Handle the outcome

The page reports the result with a single message — the same shape on every platform:

{ "type": "success" | "denied" | "error", "payload": { ... }, "v": 1 }

In a web or <iframe> embed, listen for it on the window:

window.addEventListener("message", (event) => {
  const { type, payload } = JSON.parse(event.data);
  if (type === "success") {
    console.log("payment confirmed", payload);
  }
});

Native apps receive the same message through their WebView bridge, so a single build covers iOS, Android, and the web.

For full control over the look and feel instead, embed the web components directly.