Privacy Policy

Effective date: September 16, 2026

AuthPay (“AuthPay,” “we,” “us,” or “our”) is a business payment tool for healthcare practices and their authorized staff. This Privacy Policy explains how we collect, use, and share information when staff use the AuthPay portal and when patients use an AuthPay checkout link or receive a payment notice. It should be read with our Terms of Service.

Practices remain responsible for their own HIPAA programs, patient notices, and consents. AuthPay does not replace a practice’s HIPAA compliance program, and this policy is not a Business Associate Agreement.

1. Roles

  • Practice / covered entity (or business associate of a covered entity): controls patient relationships and decides when payment links, reminders, card-on-file charges, or scheduled charges are sent.
  • AuthPay: provides staff accounts and portal tools; hosts the patient checkout page; sends payment email and SMS (including reminders); and asks the payment processor to charge a saved method when staff collect a current balance or a payment-plan installment is due.
  • Payment processor: for AuthPay checkout and Tebra payment links, Accept.Blue tokenizes card details in a hosted iframe, vaults payment methods the patient agrees to save, and processes charges. Some older unpaid links still use an Accept.Blue invoice page. Other practice types may use a different configured processor.
  • Practice systems: practice management / EHR sources for appointment, patient, and charge metadata the practice connects.

2. Information we collect

  • Staff account data: name, email, role, tenant/practice association, authentication credentials (hashed), invite and reset tokens, and session activity.
  • Practice configuration: tenant settings, branding and logo, contact details shown on notices and checkout, integration credentials, discount and payment-plan settings, and operational preferences.
  • Practice-system metadata: appointment, patient, and charge identifiers and related fields the practice authorizes AuthPay to retrieve so staff can select balances and send payment links.
  • Checkout and billing details: on AuthPay checkout, we display and store information needed to show the invoice — typically patient name, email, phone, billing address, line items or a flat amount, invoice number, due date, and amount due. Patients may apply a practice discount code and may split an eligible balance into two payments. A payment plan cannot be combined with a discount or a split.
  • Payment workflow metadata: link send status, amounts, channels, reminder history, transaction references, and limited status information returned by the payment processor.
  • Saved payment methods: if the patient leaves “save this payment method” checked (or later uses a method already on file), we store a processor token or reference plus limited card descriptors such as brand, last four digits, and expiration — not the full primary account number (PAN) or CVV. AuthPay does not intentionally store PAN or CVV. Card numbers are entered in the processor’s iframe.
  • Technical logs: IP address, browser/user agent, timestamps, and error or security logs for the staff portal and patient checkout.

3. How we use information

We use this information to authenticate staff, operate the portal and checkout page, connect authorized integrations, create and send payment links, deliver payment notices and reminders, process a charge the patient starts on checkout, store a payment method the patient agrees to save, charge that saved method when staff collect a current balance or a later scheduled amount is due (including payment-plan installments), record the payment in the connected practice system, send receipts, prevent abuse, troubleshoot issues, and comply with law.

We also use email to deliver staff invites, activation messages, and password resets.

4. Subprocessors and sharing

  • Connected practice systems — appointment, patient, and charge metadata, and payment postings, at the practice’s direction.
  • Payment processor (Accept.Blue for AuthPay checkout / Tebra links) — card tokenization, vaulting, charges, refunds, and related payment data under that processor’s systems and terms.
  • Email delivery providers — staff account email and patient payment, reminder, and receipt email (including Amazon SES where configured).
  • ACCS SMS queue and carrier workers — patient payment and reminder text messages. Messages are handed to ACCS SMS infrastructure and then to a carrier worker for delivery. The queue is not a marketing consent database; the practice remains responsible for a lawful basis to text the number staff enter.
  • Hosting / infrastructure providers — application hosting, databases, and related infrastructure.

We do not sell staff or patient personal information. We may disclose information when required by law or to protect security, rights, or safety.

5. Patient communications

For new AuthPay checkout links, payment notices, reminders, and receipts are sent by AuthPay: email through our email provider, and SMS through the ACCS SMS queue and its carrier workers. Content includes the practice name, amount due, a link to AuthPay checkout or a receipt, and related billing details the practice has already placed on the link.

Older Accept.Blue invoice pages remain payable on Accept.Blue until they are paid or expire. Reminders for those leftover links are still sent by AuthPay (email and/or SMS) and point to the Accept.Blue invoice URL. Practices must ensure they have a lawful basis and any required patient notices or consents before staff send a link or enable reminders.

6. Saved cards and later charges

On AuthPay checkout, the patient may use a method already on file or enter a new card. “Save this payment method for future payments” is checked by default; the patient may uncheck it before paying. If the method is saved, staff may charge it for a current balance without sending a checkout page, AuthPay may offer it on later checkouts for that patient, and AuthPay may charge it for scheduled payment-plan installments without showing a new card form. Checkout is used when no method is on file, when staff send an update-payment-info link so the patient can enter a new card, or when a stored-method charge is declined.

A card paid only on an older Accept.Blue invoice page is not automatically treated as an AuthPay method on file. The patient can save a method the next time they pay on AuthPay checkout.

7. Security and retention

We use administrative and technical safeguards appropriate to a staff portal and hosted checkout, including access controls, encrypted transport, and hashed passwords. Card data is tokenized by the payment processor. No system is perfectly secure. We retain account, integration, checkout, vault-reference, and workflow records as needed to provide the service, complete scheduled charges, meet legal obligations, and resolve disputes.

8. Your choices

Staff may update profile details through the portal or by asking a practice administrator. Practices may request deactivation of staff accounts. Patients may uncheck save-card, choose a different payment method on checkout, or contact the practice about a stored method, a payment plan, or a privacy request. Privacy requests relating to patient records should generally be directed to the practice; AuthPay will assist the practice where appropriate for portal- and checkout-held metadata.

9. Children

AuthPay is not directed to children under 13. Checkout links are sent so an adult responsible for a bill can pay it.

10. Changes and contact

We may update this policy by posting a revised version with a new effective date. Questions: contact your AuthPay administrator or Authorized Credit Card Systems through the practice’s ACCS relationship.