Payments

What it controls: the card processor the clinic's memberships bill through, when the EMR does not report payments to the portal. OptiMantra bills memberships through Authorize.net and does not tell the portal when a card is charged or declined. With this section set up, the portal listens to Authorize.net directly: every charge and every decline lands on the right patient, a decline sets the membership to Payment failed (and holds the refill when Refill holds is set to Hold), and the dashboard counts the week.

Where: Admin → Settings → Payments. The pill on the section header says on when a processor is set up and off when it is not.

Who can see and use it

• Everyone with View settings can open the section and see what is on file.
• The processor, its connection and the webhook are set up by Prescripta in a support session (the blue Set up by Prescripta banner says so). Clinic owners and admins see them greyed out. Contact support (Account → Support) for any change.
• Owners and admins with Change settings can change one thing themselves: the tick box A decline sets the membership to Payment failed.

Card processor (drop-down)

• None, payments are not reported. The default. The Payments page, the payment cards on the dashboard and the Payments card on each patient stay hidden.
• Authorize.net. The processor OptiMantra clinics use.
• Demo payments. Only on the demo clinic, fictional payments so every screen has something to show.

Set by Prescripta. Save writes the choice. Changing the processor takes effect right away on every screen; nothing is charged or refunded, ever, the portal only reads what the processor reports.

Sandbox account (tick box)

Shown for Authorize.net. Tick it only when the keys come from a separate Authorize.net test account (made at developer.authorize.net, it has its own login and its own keys). The clinic's normal Authorize.net account has no sandbox inside it, so for the clinic's real keys leave it unticked. Ticked with real keys, Test connection fails. Set by Prescripta.

A decline sets the membership to Payment failed (tick box)

Ticked by default. When the processor reports a declined membership charge, the portal marks the patient Payment failed (the red pill, the Payment failed dashboard card, the Payment failed alert, and the refill hold if your clinic holds refills on failed payments). Untick it and a decline is only written in the patient's Payments card, nothing else changes. Owners and admins can change this. Save applies it to the next payment the processor reports.

Past due when no charge after N days (number box)

Default 3, from 1 to 30. A membership billed by a confirmed subscription is never assumed paid: the portal knows the subscription's schedule (start date, every month or every N days), so when a scheduled charge has not come through this many days later, no paid charge from the processor on or just before that date, the morning run shows the membership Past due with the reason no charge from the card processor since MM/DD/YYYY (the Past due card, refill rules as usual). The next paid charge puts it back to Active at once. Members without a confirmed subscription keep the portal's own schedule as before. Owners and admins can change it; Save applies it from the next morning run.

Confirm subscriptions with the EMR's patient id by themselves (tick box)

Unticked by default. Unticked, every subscription the processor has waits under Payments → Subscriptions until a person confirms it, nothing reaches a patient before that. Ticked, a subscription that carries the patient's EMR id (OptiMantra writes its patient id on every subscription it creates) is confirmed on its own the first time the portal sees it; every other suggestion (card, e-mail, name) still waits for a person. Owners and admins can change it; Save applies it from the next reconcile or the next new subscription. A good time to tick it: after you have confirmed the first batch yourself and the EMR-id suggestions were all right.

Credentials (entered by Prescripta: write-only)

Only Prescripta sees this box, inside a support session. It takes the three keys from the clinic's Authorize.net account, API Login ID, Transaction Key and Signature Key (webhooks). Each one shows a pill: on file or not on file. The values are never shown again after they are saved; typing a new value replaces the old one, Remove clears one. Test connection signs in with the stored keys and reports Connected to Authorize.net (or the error). Nothing is charged.

Where the clinic finds the keys (the clinic does this part, or gives Prescripta a sign-in during setup): log in to Authorize.net → Account → Settings → API Credentials & Keys. The API Login ID is shown on that page. Tick New Transaction Key and New Signature Key → Submit; both are shown once, so copy them then. Important: an Authorize.net account has one Transaction Key and one Signature Key, and OptiMantra uses them too. A new key retires the old one after 24 hours (at once if you tick Disable Old … Immediately: leave that unticked). So in the same sitting, paste the new Transaction Key (and the Signature Key, if OptiMantra has a field for it) into OptiMantra's payment gateway settings as well, or membership charges in OptiMantra start failing the next day.

Webhook (Authorize.net → portal)

A webhook is a web address the processor sends a short message to the moment something happens, a charge, a decline, a subscription change. The portal shows the address to register under Endpoint URL to register; click in the box and it selects itself for copying. The pill next to it says Signature Key on file, deliveries are verified or No Signature Key, deliveries are refused: the portal only accepts messages it can prove came from the clinic's Authorize.net account.

• Issue webhook URL / Issue a new URL: Prescripta only. Makes the address. Issuing a new one stops the old one the same moment, so the endpoint in Authorize.net must be updated.

Registering the webhook in Authorize.net (the clinic's account; done by the clinic or by Prescripta during setup):

1. Log in to Authorize.net → Account → Settings → under Business Settings choose Webhooks.
2. Add Endpoint. Name: anything (for example Membership Management). URL: paste the Endpoint URL to register from the portal. Status: Active.
3. Tick these events and Save:
   • Payment → net.authorize.payment.authcapture.created (a charge went through), net.authorize.payment.capture.created, net.authorize.payment.refund.created, net.authorize.payment.void.created
   • Customer → Subscription → net.authorize.customer.subscription.created, …subscription.updated, …subscription.suspended, …subscription.terminated, …subscription.cancelled, …subscription.expiring, …subscription.failed (a membership charge was declined)
4. On the same Webhooks page, make sure a Signature Key exists (it is the one entered in the portal's Credentials box). If none exists, make one under API Credentials & Keys and give it to Prescripta.
5. Back in the portal the pill should read Signature Key on file. Ask Prescripta to run Test connection; then the next real charge (or the test-account charge) appears on the Payments page within a minute.

If a message cannot be delivered, Authorize.net retries on its own for a while; the portal's nightly reconcile (below) catches anything that was missed.

Reconcile

Every morning, as part of the morning run, the portal lists the clinic's active subscriptions at the processor. Each gets a row under Payments → Subscriptions with a suggested patient and how it was found, but nothing is linked until someone confirms it (see the Payments page). A subscription already confirmed gets its amount and next charge date refreshed on the membership, and its recent charges are fetched: a charge or decline whose instant notice never arrived lands on the patient then (the line says N missed charges recovered). A confirmed subscription that is no longer active is looked up: if the processor cancelled, ended or expired it, the patient is marked Billing cancelled at the processor (see below).

The line under the heading reports the last run: active subscriptions seen, how many were new, how many wait to be confirmed, how many found no patient, how many are confirmed (and how many confirmed themselves, when that tick box is on), how many stopped at the processor.

• Reconcile now: owners and admins; shown when the keys are on file. Runs the same check right away; the line updates within a minute.

How a subscription finds its patient (the suggestion)

When OptiMantra creates a membership it creates a real subscription in Authorize.net and writes OptiMantra's own patient id on it. The portal has that same id from the daily OptiMantra pull, so the suggestion is right even when a spouse's card pays or the cardholder's name is different. Order of checks:

1. the customer id on the subscription = the patient's EMR id (or a customer id learned earlier);
2. a card (type + last four) seen before on exactly one patient;
3. the e-mail on the subscription = the patient's e-mail on file (last name must agree; otherwise it is only listed as possible);
4. first and last name plus the exact membership amount, when that points at exactly one patient.

Anything else shows as Not matched. Once confirmed, the subscription itself is the link, every later charge on it lands on that patient. The portal never stores a card number, only the card type and last four digits.

When the processor and the portal disagree (Payments → Needs a decision)

The portal never settles a disagreement on its own. These are listed on Payments → Needs a decision (dashboard card Billing disagrees, review, a line in the daily summary), each with what both sides show and the choices:

Who decides: Override membership status (owners, admins and providers by default).

When the processor cancels a membership's billing

If a confirmed subscription is cancelled, terminated or expires at the processor (cancelled in Authorize.net, or cancelled in OptiMantra when OptiMantra cancels the subscription), and no other confirmed subscription still bills that patient, the portal:

• marks the patient Billing cancelled at the card processor (a red box on the patient's Payments card, the dashboard card Billing cancelled at processor, decide, the alert Billing cancelled at the card processor, a line in the daily summary);
• holds their refills (Settings → Pharmacies → Refill holds → Billing cancelled at the card processor, Hold by default);
• does not end the membership on its own, OptiMantra sometimes cancels and re-creates a subscription when the card or price changes.

A provider or admin (Override membership status) opens the patient and clicks End membership (status shows Canceled, reorders not yet placed are cancelled, refills stop) or Keep active (the hold and alert clear). If a new subscription for the same patient is confirmed, it clears by itself.

What the clinic needs to do in OptiMantra

Rule: never change the Customer ID on a subscription in Authorize.net. Authorize.net's Edit screen lets anyone change every field of a subscription, including Customer ID. On a subscription OptiMantra created, the Customer ID is OptiMantra's patient id: it is how the portal (and OptiMantra) know whose membership it is. Changing it, or typing a different patient's id, makes the processor and the EMR disagree. Change the card, amount or billing name freely; leave Customer ID alone. If it does get changed, the portal keeps the subscription on the patient it was confirmed to (the link is the subscription itself, not the id), see the Payments page for how a disagreement is shown.

What OptiMantra can and cannot do with memberships: OptiMantra has no screen that lists a patient's memberships after they are sold, changing the card on a membership requires taking a payment, and a membership cannot be cancelled in OptiMantra. To cancel a membership, cancel its subscription in Authorize.net (Recurring Billing → the subscription → Cancel); the portal then marks the patient Billing cancelled at the card processor within a minute. A membership sold in OptiMantra starts charging the next day: the subscription shows under Payments → Subscriptions right away, its first payment after Authorize.net's overnight run.

Nothing new for charges to be reported. For the suggestions to be right, memberships must be created through OptiMantra's check-out (OM then creates the Authorize.net subscription itself with the patient id on it). A subscription made by hand inside Authorize.net has no patient id; it shows as Not matched once, Find patient… and confirm, and it is linked for good. Keep the patient's e-mail in OptiMantra the same one they use at check-out, it is the portal's third check. OptiMantra's own Authorize.net settings hold only the API Login ID and Transaction Key; the Signature Key is used by the portal alone.

Questions people ask

Q: I don't see a Payments section / the Payments page.

A: The section is there for every clinic; the Payments page, nav link and dashboard cards appear only once a processor other than None is set up. Ask Prescripta to set it up.

Q: Does the portal charge or refund anyone?

A: Never. It only reads what the processor reports and shows it on the patient.

Q: A patient paid but the portal still says Payment failed.

A: Is their subscription confirmed? A charge on a subscription nobody confirmed waits on its row under Payments → Subscriptions. Confirm it and the waiting charge is applied at once, Payment failed and the hold clear. If it is confirmed, give it a minute (webhook) or wait for the morning run.

Q: Reconcile says it found subscriptions but my patients show no payments.

A: That is on purpose: nothing reaches a patient until it is confirmed. Open Payments → Subscriptions, check each suggestion, tick and Confirm selected. Confirming imports each subscription's last 20 charges onto the patient.

Q: I cancelled the membership in OptiMantra (or Authorize.net). What does the portal do?

A: When the processor reports the subscription cancelled, the patient is marked Billing cancelled at the card processor and refills are held. Open the patient and click End membership or Keep active. If OptiMantra did not cancel the Authorize.net subscription, the processor keeps charging, cancel it there too.

Q: The decline came from a card that is not the patient's.

A: That is fine, the subscription carries the patient id, so the decline lands on the right membership whoever's card it is.

Q: Who sees the card number?

A: Nobody. The portal keeps the card type and last four digits only, so you can tell a patient "the Visa ending 8174 was declined."

Q: Can we get the Signature Key from Prescripta?

A: No, keys go in, never out. Make a new one in Authorize.net if it is lost and give it to Prescripta again.