Skip to main content

Orders and Prescriptions

This page explains the complete lifecycle of an order in RxScale — from the moment a patient places it to the moment they receive their medication.

How Orders Flow Through the System

When a patient places an order through your shop, it triggers a series of steps managed by RxScale:

Order Lifecycle Step by Step

1

Order created

The patient completes a checkout in your shop. An order is created in RxScale with a status of “init”. The system validates the order and begins processing.
2

Processing started

The system verifies the order details, checks product availability, and prepares the prescription request for doctor review.
3

Waiting for doctor

The prescription is placed in a doctor’s review queue. The doctor reviews the patient’s questionnaire responses and medical information.
4

Doctor decision

The doctor either approves, declines, or places the prescription on hold.
  • Approved — The prescription moves to signing.
  • Declined — The order is updated and the patient is notified.
  • On hold — The prescription is paused for additional information.
5

Prescription signed

The doctor electronically signs the prescription using a qualified electronic signature (QES). This makes it legally valid.
6

Sent to pharmacy

The system routes the order to an appropriate pharmacy based on product availability and location.
7

Pharmacy processing

The pharmacy reviews the order, prepares the medication, and ships it to the patient.
8

Order completed

The patient receives their medication and the order is marked as completed.

Prescription Management

Prescription Creation

A prescription is created automatically when an order enters the doctor review stage. You do not need to create prescriptions manually — the system handles this based on the products in the order.

Reserving a Share for One Doctor

In the Admin Tool, you can configure one doctor in your organisation to receive a percentage of eligible new prescriptions. For example, a queue share of 30% reserves approximately 30% of new prescriptions for that doctor while the remaining prescriptions stay in the shared review queue. The doctor must still be eligible for each prescription. Signing permissions, prescription type, questionnaire access, and SKU blacklists continue to apply. An ineligible prescription remains in the shared queue instead of being reserved for a different doctor. Only prescriptions that are ready for review are reserved. A prescription whose questionnaire has not been answered yet is not reservable, because no doctor can pick it up at that point. Each reservation has an overflow timeout. If the selected doctor does not take the prescription before that timeout, RxScale releases it to the shared queue so another eligible doctor can review it. Only one doctor per organisation can have a queue share above 0%.
A reservation is not an assignment. The prescription stays unassigned until a doctor actually takes it, so doctor_uid is still null while the reservation is held, and reserving or releasing a reservation sends no webhook. You receive the usual prescription.doctor_changed event with doctor_assignment_reason set to QUEUE_ASSIGNED at the moment a doctor takes the prescription — whether that is the doctor it was reserved for or, after the timeout, anybody else. Queue sharing adds no new fields to prescription webhooks or Management API responses. See Webhooks and Notifications.

Prescription Statuses

For detailed status descriptions, see Prescription Statuses.

Downloading a Prescription

Open an order in the Admin Tool and use the download menu in the Prescriptions section. Three options are available once a prescription is signed: Use the copy whenever the PDF is going to someone outside your organisation. The watermark makes clear that the document is a duplicate and not the signed original.
If a prescription PDF cannot be watermarked — for example because it is password-protected — the copy download fails and returns no file. This is deliberate: you will never receive an unmarked original when you asked for a copy. Use Download prescription file if you need the original.

Working with Pharmacy Partners

Once a prescription is signed, RxScale handles pharmacy assignment automatically. The system considers:
  • Product availability — Whether the pharmacy has the required products in stock.
  • Location — Geographic proximity to the patient for faster delivery.
  • Capacity — The pharmacy’s current workload.
You do not need to manage pharmacy relationships directly. RxScale takes care of routing orders to the right pharmacy.

Monitoring Orders

You can monitor order progress through:
  • Webhooks — Receive real-time notifications when order or prescription statuses change. See Webhooks and Notifications.
  • Management API — Query order and prescription details programmatically. See Management API.

Storefront Payments and Refunds

When a patient orders through your RxScale-hosted storefront, they pay the review fee through your connected Mollie account before a doctor sees the request. Only a successful payment creates the order, so every storefront order in the admin dashboard has a payment behind it. Open the order in the admin dashboard to see its Payment card:
  • the payment status (for example Paid, Partially refunded or Refunded), and a Test mode badge for payments taken in Mollie’s test mode
  • the amount, how much has been refunded and how much can still be refunded
  • the VAT rate recorded at checkout and the RxScale platform fee
  • the Mollie payment ID (tr_…), which you can search for in your Mollie dashboard
  • every refund made against the payment, with its status and reason — and, for a refund that failed or has not gone through yet, the reason why

Refunding a Storefront Payment

Choose Refund on the Payment card. Send back everything that is still refundable (Full refund) or a smaller amount (Partial refund), and optionally add a reason — some payment methods show it to the patient. The refund is sent to Mollie straight away; the dialog stays open until Mollie has answered, and the card updates when it closes.
  • The platform fee is not refunded. If RxScale charged a platform fee on the payment, Mollie does not return it with a refund: the patient gets back what they paid, and RxScale keeps its fee.
  • Test payments move no money. Refunding a test-mode payment repeats the flow at Mollie but sends nothing back.
  • If Mollie does not answer, the refund stays Pending and the action changes to Retry refund. Retrying completes that same refund instead of creating a new one. If the refund has been pending for more than an hour, check the payment in your Mollie dashboard before you retry: Mollie only recognises a retry as the same refund for about an hour.
  • A refund does not change the prescription or the order. It is a back-office decision, separate from the doctor’s review.

Order Numbers for Storefront Orders

Orders from your Shopify shop keep the name Shopify gives them, such as #1525. Orders placed through an RxScale-hosted storefront have no Shopify order behind them, so RxScale numbers them itself: each storefront counts up from RXS-1001, then RXS-1002, and so on. Only paid orders get a number — an abandoned checkout does not use one up. The number is shown in the admin tool as the Shop ID in the order list and as Shop Order on the order page, and you can search for it. Pharmacies receive it as shop_order_name once you have enabled the shop order name for them. Each storefront can use its own prefix instead of RXS — contact RxScale to set one. A changed prefix applies from the next order on: the count continues, and orders that already have a number keep it.

Shopify Priority Settings

If your shop uses Shopify, you can pass priority values to RxScale so urgent patients or orders are surfaced ahead of normal-priority work. Use integer values; higher numbers mean higher priority. Missing or invalid values are ignored and the default priority is used. Order priority applies to the specific Shopify order. Patient priority is stored on the patient profile and can be reused across the patient’s future activity.
Store priority values as plain integers. Values such as high, urgent, or empty strings are ignored instead of being converted to a priority.

Placing Prescriptions on Hold

If your shop uses Shopify, you can have a prescription created on hold instead of sending it into the regular review queue. That is useful when an order needs a manual check first (for example, awaiting a lab result or an identity confirmation). The prescription stays unassigned and appears in the organisation’s doctor worklist with the hold reason, so a doctor in that organisation can pick it up when ready. Set the hold intent through order attributes:
  • The prescription is placed on hold only when _rxscale_prescription_hold is a truthy value: true, 1, or yes (case-insensitive). Any other value — or a missing attribute — creates the prescription normally.
  • _rxscale_prescription_hold_comment is optional. When present alongside a truthy hold, the reason is recorded on the prescription’s status history and shown to the reviewer. The comment is ignored if the order is not held.
  • The hold is applied when the prescription is first created. Adding the attribute to an existing order later does not retroactively hold an already-created prescription.
The hold applies to the prescription only. The order itself continues through its normal lifecycle.

Confirming Patient-Doctor Meetings on Payment

If your shop uses Shopify and the storefront books a patient-doctor meeting before checkout, you can automatically confirm that meeting when the order is paid. Set the meeting UID on the order and/or line item:
  • Confirmation runs only when the order financial status is paid.
  • You may attach one UID per attribute occurrence (for example one on the order and one per line item). Duplicate values are confirmed once.
  • Missing, already confirmed, cancelled, or otherwise non-confirmable UIDs are skipped without failing order ingest.
  • A successful confirm emits the same meeting-updated webhook events as confirming the hold through the scheduling API.
  • A meeting that carries its own price is not confirmed this way. If the meeting was booked through a booking link that charges for the appointment, it is confirmed only once that appointment payment settles — paying for the order does not pay for the appointment. The UID is skipped (order ingest is unaffected), the meeting stays held until its hold expires, and the patient can still pay for it on the booking page while the hold lasts.
This applies only to meetings booked through a priced booking link. A meeting booked without an appointment price — which is every meeting booked before appointment payments existed, and every unpriced link since — confirms on payment exactly as before.

Skipping RxScale Order Import

If your shop uses Shopify, you can prevent RxScale from automatically importing an order via Shopify webhooks (and from processing later webhook updates or cancellations for that order) by setting an order additional attribute:
  • RxScale skips the order only when the attribute value is true (case-insensitive). Values such as 1, yes, false, or a missing attribute do not skip import.
  • While the attribute is set, automatic Shopify webhook processing does not import, update, or cancel-process the order in RxScale. An order that was already imported earlier is left as-is; further Shopify webhooks for that order are ignored until the attribute is removed or no longer true.
This is different from _skip_validation / _rxscale_skip_validation, which still import the order but skip anamnesis validation for prescription items.

Age Limit for Shopify Order Webhooks

RxScale ignores Shopify order webhooks for orders created more than 60 days before the webhook was sent. This keeps bulk edits, tag sweeps, and archive migrations of long-closed orders from re-entering the RxScale pipeline.
  • The limit applies to order creation and order update webhooks.
  • Order cancellations are always processed, however old the order is.
  • The age is measured from the order’s creation date in Shopify to the moment the webhook was sent — not from the date you edit the order. Editing a two-year-old order therefore has no effect in RxScale.
To get a change into RxScale for an order past the limit, create a new order. If an older order genuinely needs to be imported, contact RxScale support. An order that already exists in RxScale with no fulfillment records cannot be imported again — it was already dispatched by the previous system, and re-importing it would create a duplicate prescription. This does not apply to an order RxScale never imported in the first place; a genuinely old order like that can still be brought in normally.

Delivery Type from Shopify Line Properties

If your shop uses Shopify, RxScale reads the line item property _fulfillment_method or fulfillment_method and maps that value to a delivery type configured for the shop (for example pickup → pharmacy pickup). The unprefixed fulfillment_method key is the name Shopify’s admin shows when the storefront sets a line property without a leading underscore.
  • If both keys are present, _fulfillment_method is used.
  • The value must match a delivery type mapping configured for that shop. Unmapped values leave the fulfillment order without a delivery type; the pharmacy default may still apply later.
  • _delivery_type (for example physical) is a separate product property and is not used as the shipping type.

Pharmacy Orders in the API

When you retrieve orders via the Management API, each order includes a pharmacy_orders array showing how the order is being fulfilled:
Each pharmacy order represents a fulfillment attempt by a pharmacy. An order may have multiple pharmacy orders if it was reassigned to a different pharmacy.
delivery_type is resolved from the connected shop’s fulfillment method (the Shopify line item property _fulfillment_method or fulfillment_method, mapped per shop), otherwise from the receiving pharmacy’s default delivery type. It may be null when neither is set, so do not assume a delivery type is always present.

Pharmacy Order Statuses