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… | Use | Who 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.
| Event | When it fires |
|---|---|
payment-success | The payment was confirmed. |
payment-denied | The gateway rejected the payment. |
payment-error | Authentication 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.