Payment Contracts


Our goal is to help our practices get paid, as much as possible, as quickly as possible. Payment Contracts is an offering that allows us to automatically collect patient balances associated with claims up to the agreed-upon amount set by the patient covered by the contract. athenahealth aims to increase adoption of payment contracts through Digital Check-in capability.  

This documentation focuses on two types of Card-on-File Contracts that athenahealth supports:

-Single Appointment: automatically charges a patient using the authorized card on file after the payer has (or payers have) completed adjudication for claims associated with this appointment.  This contract type will charge up to a designated dollar limit for just the single appointment for which the contract is signed. The API endpoint for this is /patients/{patientid}/collectpayment/singleappointment/{appointmentid}.

-One Year Contract: charges the patient for every outstanding charge after the payer has (or payers have) adjudicated claims incurred within 1 year of the contract date. This contract type will charge up to a designated dollar limit for all appointments within 1 year of when the contract is signed. The API endpoint for this is /patients/{patientid}/collectpayment/oneyear/{appointmentid}.  

Note 1: Both contracts require the athena Credit Card Plus (CCP) product at the practice level. Note 2: Neither contract type will operate on existing balances at the time the contract is set.

High-Level Patient Workflow (applies to both payment contract types):

  1. Practice submits claim
  2. Payer(s) adjudicate claim
  3. If patient has a balance, email the patient a notification of the impending charge
  4. 5 days later, charge the credit card on file. During these 5 days, the patient can contact the practice to cancel the contract
  5. Email a receipt to the patient

To establish a payment contract, the patient must:

  1. Be presented the contract terms (static language with dynamic contract dates only)
  2. Confirm/override existing email address 
  3. Confirm/override the per-practice default maximum dollar amount
  4. Provide valid credit card information
  5. Sign the contract receipt (which includes a copy of the terms)   

The output of the API call for either contract type gives an epaymentid. This is then used to get the receipt via /patients/{patientid}/receipts/{epaymentid}. Subsequently, the signed receipt should be uploaded via a POST to /patients/{patientid}/receipts/{epaymentid}/signed.  

Note: If a signed receipt is not uploaded, the contract will be canceled automatically without charging the patient.

The credit card is charged for any amount up to the maximum amount set for the contract. Any remaining balance remains due on the patient’s account.  

Payment Contract Notes

- In order to support payment contracts, the department must have a Retail MID in place, and must have an auto contract department in place (this is the department on which the contracts run in the background later when charges actually hit). This is usually set up automatically, but we recommend the API user makes sure this exists during client implementation. (Clients can check this in Gear Icon -> Billing Admin -> Departments … check for Auto Contract Department. If there isn't one, have the client call the CSC and we will add it in.)

- You must look at the /departments call to determine which departments support credit card contracts. Currently any department that accepts credit cards will show they accept payment contracts as well. 

- You will find the default maximum amount for either contract type in the /departments call. If there is no maximum provided, that contract type is not available for that department. Note that credit card types accepted are available via the same call. There may be one edge case where a department accepts credit cards but not payment contracts, therefore we recommend API users confirm with practices during implementation (when asking which type of contracts to surface in the UI). 

- Where a department supports payment contracts, it automatically supports both contract types. Practice policy determines which contract type should be offered. Similarly, the practice should choose which to implement for Digital Check-in at the practice/provider group/department level. This should be handled between the you and practice during onboarding. We strongly suggest keeping this simple in the solution's UI by offering only one.

- The maximum contract limit for each contract type is set by the practice in athenaNet. The system generates default maximums, and practices can adjust those under Gear Icon -> Billing Admin -> Credit Card Plus settings. The athenaNet default maximum is $150 for Single Appointment and $1,500 for One Year. These defaults can be modified by the practice at the merchant location level. Each merchant location may include one or more departments. The patient may override the suggested maximum amount in the solution's UI (assume this would be lower, but system supports higher limit as well). This is something the front desk staff can already do in athenaNet.

- Determine if there is already an active One Year contract for this patient, in which case a new contract should not be presented. This is supported through the list of existing contract API calls: List of Existing One Year Contracts (GET /v1/{practiceid}/patients/{patientid}/collectpayment/oneyear) and List of Existing Single Appointment Calls (GET /v1/{practiceid}/patients/{patientid}/collectpayment/singleappointment).

- API users can access standard contract terms via API, ensuring athenaNet remains the single source for contract terms. Please note that Single Appointment and One Year contract terms are different, so be sure to request the proper terms for your contract type. 

- An email address must be associated with a payment contract. The patient may wish to use a different email address for this purpose, therefore we recommend pre-populating the email address on file and allowing the patient to confirm or override it. If a patient overrides with another email address, this will not replace the primary email we have on file for them (this payment contract email is stored separately). We strongly recommend that the solution require double entry when entering a new email address, or ask the patient to validate the email on file.

- Our recommended best practice is to present copay and prior outstanding balances separately from the payment contracts to avoid confusion. All of these transactions (copay, outstanding balance, contract creation) can be done with one credit card swipe, but require two transactions (two API calls) and two signatures, as different data is needed for the copay and balance vs. the contract (i.e. we don’t want to send CVV2 data with swipe data, but since we use a MOTO MID for contracts, we need the CVV2). Note: This requires the API user to temporarily store the credit card information in memory between the two EPayment API calls (first is for Copay and Balance, the second is for contract creation). The solution should be sure not to permanently store the credit card information to avoid any violation of PCI rules. The two transactions will generate 4 back-end receipts (one merchant copy, one customer copy each), two of which are patient facing for signature (merchant copies). If printing is desired, the solution should print the customer copy. The /patients/{patientid}/receipts/{epaymentid} call allows you to request the “merchantversion” and/or the “customerversion”. API users should make it clear in their UI that any prior outstanding balance is not covered by a new payment contract. It is up to the partner to decide if they’d like to present this before or after the payment contract.

- Please see this page about emailing patient receipts.

- The signed contract receipt (the same thing as the “signed contract”) will be stored in athenaNet as a PDF. API users can also pull a PDF for printing, etc., via the API. (In the past the practice was responsible for printing and storing a signed paper contract on site, though for Digital Check-in, we have created the ability to store or retrieve the signed PDF contract in athenaNet with /patients/{patientid}/receipts/{epaymentid}/signed.)

Illustrative Patient Workflow:

Copay and Outstanding Balance (or this may be presented after payment contract)

  1. Patient is presented with today’s copay amount and prior outstanding balance, per the standard workflow.  
  2. Patient enters amount of outstanding balance they’d like to pay, swipes card, and signs with finger on device. (Future functionality will support displaying outstanding balance at the claim level and allowing the patient to indicate how much they’d like to pay toward each. There will be separate documentation about this when ready.)

Payment Contract

  1. If today’s appointment is not covered by an existing One Year contract, patient is presented the terms for the appropriate contract.
  2. Patient enters/confirms email address through which they’ll be notified of charges.
  3. Patient confirms or overrides max amount for this payment contract.
  4. Patient acknowledges they’d like to use the same card for this transaction, or swipes a different card (it’s up to the solution whether they’d like to assume the same card or present the patient the option to use a different card).
  5. Patient signs contract receipt via the device ("fingerture"). If patient doesn’t wish to sign, direct them to the front desk to discuss further or pursue alternative payment options per practice policy.
  6. Patient may request a printed copy of the contract receipt at the front desk (in which case ideally solution can trigger printing at front desk). 
Was this information helpful? Yes | No What went wrong? Incomplete or incorrect information | Irrelevant Content | Others