Payments
Telehealth payments, on your own merchant.
Charge, subscribe, and refund through your own merchant account — with billing built for recurring therapy and refunds tied to the order saga so money and fulfillment never drift apart. Cardholder data is tokenized client-side and never touches our systems.
What's inside
Billing that keeps up with care.
Merchant accounts, subscriptions, refunds, and minimized PCI scope — exposed as API.
Telehealth-ready merchant accounts
Payment setup built for virtual care, on each client’s own merchant account — your payments, your margin.
Subscriptions & rebills
Recurring therapy billing with dunning and retries, so refills bill themselves and revenue doesn’t leak.
Refunds & adjustments
Issue refunds programmatically — wired to the order saga’s compensation path, so a refund and a cancelled order can’t drift apart.
Card data never touches us
Client-side tokenization keeps cardholder data off our systems — SAQ-A scope, not full PCI-DSS. (unconfirmed claim — pending verification: PCI scope (SAQ-A) & tokenization wording — confirm with counsel before launch)
Your merchant, your margin
Payments run through your own merchant account — no platform middleman taking a cut of every charge.
Callable by your agents
Create charges and subscriptions, issue refunds, and react to payment.captured events through the API.
How it fits
A refund is just the saga, run backwards.
Payments aren’t a standalone integration — charges and refunds are steps in the durable order workflow. When an order can’t be completed, the saga’s compensation path reverses the charge automatically. Idempotency keys mean a retried charge is a no-op: at-most-once billing.
POST /v1/subscriptions
{
"patient_id": "pat_77a1...",
"plan": "monthly-therapy",
"payment_token": "tok_live_..."
}
201 Created
{ "subscription_id": "sub_9k4d...", "status": "active" }Illustrative — the live API surface is published in the docs.
Get started