Confirm a pack payment
Settle a standalone pack purchase and mint the pack.
POST /v1/session/packs/confirmThe second half of buying a pack. Medos reads the payment at the gateway and, if the money landed, creates the pack and credits the patient's session wallet. Until this succeeds the patient owns nothing — the pack is created on verification, not on checkout.
Not OTP-gated: the unguessable sessionRef scopes it to the client that started
the purchase.
Body
| Field | Type | Required | Description |
|---|---|---|---|
sessionRef | string | Yes | From the purchase response. The only field this route reads. |
Try it
/v1/session/packs/confirmBody
POST /v1/session/packs/confirm{}https://api.medos.oneUse a dedicated test key, and put your browser's address on its allowlist
A Developer API key authenticates on its own, so it only works from the addresses registered against it — and this page calls from your browser, not your servers. Unless your own public address is on the list you get a 403 naming it, which is the allowlist doing its job. Your browser may also reach us over IPv6 even when your server does not, so the address in the error is often not the one you expected. The key here is kept in memory only and never written to storage, but create a test key for it and deactivate that key when you are done.
Request
curl -sX POST "https://api.medos.one/v1/session/packs/confirm" \
-H "x-api-key: $MEDOS_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "sessionRef": "pks_01J9ZB4M7T" }'Response
{
"status": "SUCCESS",
"patientPackageId": 4411,
"walletBalanceAfter": 10,
"paymentStatus": "PAID",
"message": "Payment verified"
}| Field | Meaning |
|---|---|
status | SUCCESS, FAILED or PENDING. |
patientPackageId | The pack that now belongs to the patient. This is what a USE_ACTIVE_PACKAGE booking spends. Store it. |
walletBalanceAfter | Sessions credited and unused. |
paymentStatus | The purchase's settlement state at Medos. |
message | Detail from the payment rail — the only place a terminal reason is spelled out. |
What each status means
status | What to do |
|---|---|
SUCCESS | The pack exists. Stop polling and show it to the patient. |
FAILED | The payment failed or the checkout expired. Offer a fresh purchase. |
PENDING | Not settled yet. Poll again. |
Bound your polling
PENDING is the catch-all, so it also covers cases that will never settle.
Poll on a decaying interval for a few minutes, then stop and read message
rather than waiting indefinitely.
Common failures
| Status | Cause |
|---|---|
400 | sessionRef missing, or belonging to a purchase in another workspace. |
Safe to repeat
This verifies at the gateway; it does not charge, and it will not mint a
second pack for a session already settled. Calling it again after a SUCCESS
returns the same result.