Mediquo documentation home
Checkout

Web components

Embed the checkout directly in your UI for full control over the payment experience.

When you need the checkout inside your own interface — fully themed and part of your layout — drop in one of the two payment web components. Both embed the Mediquo payment portal, poll until the payment resolves, and report the outcome through the same events. You pick the one that matches how the charge is created.

If you'd rather not build any UI, the hosted checkout is the shorter path.

Choose a component

You want to…UseWho creates the session
Charge for a booked appointment<mq-appointment-checkout>The component, from a slot and service
Charge for anything else<mq-checkout>Your backend, via a callback

If you're charging for an appointment, reach for <mq-appointment-checkout> first — it's the shortest path. Drop down to <mq-checkout> when you need full control over how the payment session is created.

Charge for an appointment

Give the component a slot-id and a service-id. It creates the payment session for you and runs the rest of the flow.

<mq-theme-provider theme="mediquo">
  <mq-appointment-checkout
    env="production"
    api-key="<your-api-key>"
    token="<your-token>"
    slot-id="<slot-uuid>"
    service-id="<service-uuid>"
  ></mq-appointment-checkout>
</mq-theme-provider>

See the <mq-appointment-checkout> reference for every attribute and event.

Charge for a custom session

Create the session on your backend and return it from a provideSession callback. The component handles the portal, polling, and retries.

<mq-theme-provider theme="mediquo">
  <mq-checkout id="checkout" env="production" api-key="<your-api-key>" token="<your-token>"></mq-checkout>
</mq-theme-provider>

<script type="module">
  const checkout = document.getElementById("checkout");

  // Called on the initial load and again on every retry.
  checkout.provideSession = async () => {
    const res = await fetch("https://your-backend.example/payments", { method: "POST" });
    return res.json(); // { sessionId, paymentUrl }
  };
</script>

See the <mq-checkout> reference for the full provideSession contract.

Handle the outcome

Both components emit the same events, so your success and failure handling is identical regardless of which one you use.

EventWhen it fires
payment-successThe payment was confirmed.
payment-deniedThe gateway rejected the payment.
payment-errorAuthentication failed, the session couldn't be created, or polling timed out.
checkout.addEventListener("payment-success", (e) => {
  // e.detail.appointmentId for mq-appointment-checkout
  // e.detail.reference     for mq-checkout
  console.log("paid", e.detail);
});

Retries are automatic — when the portal asks to try again, the component requests a fresh session on its own. You don't need to handle payment-retry.