This article covers the most recent version of our TSYS Payment Processing integration, providing a one stop resource for processing payments, setting up recurring payments, and handling online patient payments.

This article assumes you are using MacPractice Build 12.21, as all of the features described in this article are available in this build. You also have access to Online Patient Payments, which is covered in this article here.

If you are on MacPractice Builds 12.11 and below, you will want to refer to TSYS Integration Set Up and Usage Guide (12.11 and earlier) instead.

MacPractice Support can assist with the MacPractice integration of TSYS Credit Card Processing, but any issues regarding the hardware or a failure to process a credit card payment should be brought to the TSYS ISV Care Team. TSYS will also provide you with any passwords required for the Card Processing Machines. Their phone number is (855) 882-0507 if you ever need to reach out to them.

Set Up Instructions

In order to successfully set up TSYS, you'll need to have Domain Management set up on their MacPractice account. You'll also need to be running MacPractice Build 12.21.

You will need to have your TSYS-provided Card Processing Machine connected to the same network as the MacPractice Server via an Ethernet connection.

You will also need your TSYS credentials, which will include:                         

• The TSYS Device ID

• Your TSEP ID

• The TSYS Device Username

• The TSYS Device Password

• The TSYS Device's IP address

You will need these credentials for each Card Reader you have connected. These will be provided by TSYS and MacPractice Support cannot assist with this step.

Adding a new Device

When the client has these credentials, you can begin to set up the Card Processing Device to work with MacPractice. You will need to do this for each MacPractice computer in your office that you intend to process payments on.

To add a new device, navigate to the MacPractice Menu > Preferences > TSYS and click the Green Plus above the Card Processing Devices table. Clicking this will open up a new window where you can enter the details of the Card Processing Device.

You'll note that all the fields except Device Nickname and Device IP address are marked red as required. The Device Nickname is an identifier solely used in MacPractice to distinguish between PAX Card Readers (for example, you could set a Nickname as "Front Desk Card Reader", or "Back Office Card Reader", etc as necessary to clearly identify your different readers.

Switching, Resetting, and Rebooting Devices

If you have multiple devices connected to your network, you can direct MacPractice to utilize a specific Device by clicking it in the Card Processing Devices table and then clicking the "Use This Device" button.

You can also select a device and use the drop down "More" selector to either Reset or Reboot the selected device.

What's the difference between resetting and rebooting?

• Reset Device: This option will interrupt any ongoing interaction and return the credit card reader to an idle state.

• Reboot Device: This option will fully reboot the credit card reader, effectively powering it down and restarting it. The device will first finish up all tasks, such as processing credit cards, before rebooting.

Address Verification

In Preferences you can customize the extent to which you utilize Address Verification features in TSYS Preferences. 

We know that not all offices have the same AVS requirements set up on their account so we will allow users to set their AVS options specific to their requirements in Preferences > TSYS.

Regardless of what options are set here, setting up an account's Wallet will require both Address and Zip Code verification. 

Setting the Default Payment Type

We've added a new Ledger Preference: the Default Payment Type (After Entering New Charges). This Ledger Preference is located in the New Charge tab.

This Preference works in conjunction with the "Show Payment Window" option after entering a New Charge. It will automatically select the payment type you have set in the Default Payment Type drop down menu.

It is important to stress that this Preference only needs to be set if you have the "Show Payment Window" preference enabled.

Insurance Credit Card Payment Type

In addition to the new Default Payment Type preference, we've also added in a new Payment Type, Insurance Credit Card, which grants the ability to process Insurance Credit Cards through TSYS. This can be selected like any payment method in the Payments Menu of the Ledger.

This change will be reflected in several reports that track insurance payments.

With this addition, you are able to create your own custom payment types for Insurance Credit Cards. You can do this by adding a new type to the Payment Type Reference, located in the References Ability.

The purpose for adding a custom Payment Type is for your organizational purposes. If you want to track a specific type of insurance credit card payment, say from a particular insurance company, you could add a custom Payment Type which you could then track more easily via our Reports.

Setting the TSYS Card Receipt Form (optional)The last step is to set a Card Receipt Form in Preferences so when you print off a Credit Card Receipt, MacPractice knows which form to use.

You can set this in advance by navigating to Preferences > Forms.

If you attempt to print a credit card receipt and no form is selected, MacPractice will use the Default TSYS Card Receipt Form. If this form does not appear, you can confirm it is present in your MacPractice database by navigating to References > Forms and locating the "Default TSYS Card Receipt Form" in the sidebar. You simply need to ensure the "Form Active" checkbox is enabled below the Name field.

Processing Credit Card Payments

When a Credit Card Processing Machine is properly set up in TSYS Preferences and TSYS is enabled on your license, you're ready to begin processing credit card payments.

You'll first navigate to the Ledger, and you'll create a Patient Payment or an Insurance Credit Card payment from the Payment Menu.

The first thing you'll notice when you open up the Payment Window is that the layout is a little different. We took the opportunity when implementing TSYS integration to re-organize the Payment Window for better workflow and clarity.

Without the TSYS feature on your MacPractice license and no valid Credit Card Machine is connected, the Payment Window would look like this. If your Payment Window looks like this, double-check that you have followed the steps in the TSYS Preferences and Set Up section.

When you do have a valid credit card machine connected to this computer, your MacPractice Payment Window will instead appear as so:

You'll notice that in the upper right corner, a "Card Entry Method" pop up menu and a new button are available. The pop up menu is used to select the method of processing the credit card payment.

There are five processing options available. There is also a Payment Type of ACH available, but this can only be used for Recurring Payments.

Processing Options

Each of these is a particular method for processing the payment, divided up into three methods; Transmit, Manual, and Forced. We'll describe each one in turn.

• Credit - Manual
• Credit/Debit - Transmit
• Forced Transactions (Credit - Forced)
• Card on File

Credit - Manual

Credit - Manual allows a user to manually enter in credit card information from MacPractice.

When you enter an amount for the credit card payment and select this option from the Card Entry Method drop down, the button immediately below the drop down menu will change to "Manual Entry".

When you click the Manual Entry button, it'll bring up a window where you can enter the card details. This method has the advantage of not needing the card reader physically present, which is great for situations such as processing payments made through statements or mail. (although the Card Reader must still be available on the same network as the MacPractice Server!)

The Card Number and Expiration Date fields are required. CVV may be necessary depending on how your TSYS account and hardware is configured.

Once you click Submit, you'll be returned to the payment window, and you'll see a spinning wheel below the Manual Entry button. Once it completes, you'll get a confirmation message listed in the Payment Window, as shown in the screenshot below.

From here, the approved credit card transaction will reside in this payment on the ledger. You also have until the credit card batch is closed and approved to void the transaction by using the "Void Transaction" button, which we'll discuss later in Voiding Transactions.

Credit/Debit - Transmit

The Credit - Transmit and Debit - Transmit options both allow you to use a credit/debit card on your card processing device, via swiping, or tapping, or any method the card reader supports. For our purposes, we'll refer to this action as "swiping". The "transmit" phrase refers to transmitting the card information from the machine to MacPractice.

Functionally, the Transmit option works similarly to the Manual option. In the payment window, you'll enter in the Amount as normal, then select the Credit or Debit - Transmit option from the Card Entry Method drop down. Upon selection, you'll see the button below the drop down menu change to "Transmit to Device". When this is clicked, the payment window will have a spinning indication that says "Waiting for Device". At this point, you should swipe the credit or debit card.

If you wait too long to swipe a card, the "Waiting for device..." prompt as shown in the above screenshot will time out.

Depending on how your PAX card reader is configured, the patient may need to verify additional information, and will be prompted via the device. When the card processes successfully, you'll see a confirmation message in the Payment Window, much like the Manual method.

Forced Transactions (Credit - Forced)

Normally, the Credit - Forced option is used when you have received a Declined message after attempting to process a card via the first three methods, as shown in the screenshot below.

In this situation, a patient can contact the credit/debit card company's phone number (typically printed on their card) to obtain an Auth (Authorization) code that will allow the payment to be processed.

When you receive the Declined message, select the Credit - Forced Card Entry Method from the drop down. The button will change to "Force Transaction".

When you click this button, a prompt will appear asking for an Auth Code, and the card information again.

The Forced method can also be used to re-enter a credit/debit transaction that was deleted from the card reader, or if the connection from the card reader to TSYS was interrupted. By accessing the transaction/auth # from the TSYS portal and entering it into the Auth Code field, you can re-enter this information into MacPractice without re-processing the card.

Card on File

This option will allow you to select a Card on File in the Account's Wallet. We cover Setting Up the Wallet in a later section of this article here.

When selected, an additional drop down menu will appear below the Card Entry Method menu which will allow you to either select one of the cards that are on file in this account, or you can add a new one on the fly.

• Credit - Manual
• Credit/Debit - Transmit
• Forced Transactions (Credit - Forced)
• Card on File

Partially Approved Payments

When a credit/debit card is processed and there is not enough available on the card, you may see a Partial Approval prompt window.

This window contains an explanation of the situation, demonstrating that only a portion of the payment was approved. At this point, you can choose, at the patient's discretion, to either Void the transaction and make other arrangements to cover the full payment amount, or you can keep the partial approval and make other arrangements to cover the remainder of the cost.

If you've already applied the payment amount in the Payment Window before processing the card, you may be warned that in the situation of a partial approval, the applied amount will be unapplied in order for the user to apply the partial amount properly.

Receipts

You can print off a credit card receipt for patient credit card payments after running a transaction in the Payment Window by checking the "Print TSYS Card Receipt" checkbox in the Payment Window.
This checkbox is enabled by default on all new payments, and unchecked when opening an existing payment.

Upon clicking the "Save" button on the Payment Window, a prompt will appear allowing you to select the printer. The printed receipt form matches the dimensions for a DYMO Printer standard size, but you can print it off with any kind of printer.

You can also select the payment or refund in the patient's ledger and select "Print TSYS Card Receipt" from the Print Menu. You can also simply double click the receipt line in the ledger to open up the receipt, allowing you to reprint an existing receipt.

This Print TSYS Card Receipt option will allow you to also print Insurance Credit Card receipts.

Finally, you can print off both patient and insurance credit card receipts from the Transaction Log, which we'll cover in that section.

If you prefer not to have card receipts show in the ledger, you can use the ledger's View Options drop down menu to disable or enable these items.

Voiding Transactions

Voiding a Transaction can be necessary in certain situations, such as the incorrect card being processed.

Transactions are eligible to be voided presuming that the latest credit card Batch has not been closed yet. Batches are covered in the Batch Management section of this article.

There are two methods to void a transaction. First, in the ledger you can open up the payment that holds the credit card transaction and click the "Void Transaction" button, located in the upper right corner of the payment window.

The second method is to navigate to the Transaction Log node of the Accounting Ability, select the payment in question, and select "Void" from the Actions drop down menu. We'll cover this interaction more in the Transaction Log section.

If the batch has already been closed, you'll need to refund the credit card transaction, as the transaction will no longer be able to be voided. In this situation, when attempting to void a transaction, you would see an "Error - Not Found" message.

Refunding to a Credit/Debit Card

On occasion you'll need to issue a refund to a credit or debit card. Thankfully, refunding a credit card payment is as simple as refunding a normal payment.

First, select the payment in the Ledger with the credit card transaction you'd like to refund, and select Refund from the "Other" drop down menu. You will have to unapply the credit card payment  from any connected charges prior to refunding.

The Refund window will appear, and you'll note that with the "Refund Credit to Credit Card" checkbox enabled, the payment method will be displayed. In prior implementations of our TSYS Integration, a user was once able to refund to any card, but this functionality was removed in Build 12.15 of MacPractice.

If you wish to refund a higher amount than the original payment, you will need to first adjust the original payment's amount in order to refund the higher amount. When adjusting the original payment, you'll likely see an alert warning you that the new amount does not match the card transaction amount as a safety precaution.

Refunding to Check

If you find yourself in a situation where you need to issue a refund by check, the best way to accomplish this is to select the credit/debit payment in a ledger, then select Refund as you normally would, and then check the "Refund Credit by Cash or Check" option in the Refund window. You'll still need to ensure that there is an unapplied portion of the payment to refund. 

From here, you need to enter something in the Refund Reference # field. We recommend that whatever you use, you type in the method you'll be using to refund. For example, if we are refunding to a check, we'd enter "Refund to Check" into the Refund Reference # field.

When you are satisfied, click OK. This will create a refund line item in the ledger, and you can then proceed with refunding the patient.

Management Tools in the Accounting Ability

This section covers some of the additional tools and information available in the Accounting Ability. These are located in the new "Card Transactions" section of the sidebar. There's a new node for the Transaction Log, and a new node for Batch Management.

If you need to add the Accounting Ability to your toolbar, simply right click any empty space in the toolbar area and click "Customize Toolbar". From this window, you can drag and drop the Accounting Ability to your toolbar wherever you prefer it.

Transaction Log

The Transaction Log contains a history and essential information of all credit card transactions that have been processed through your connected card readers. You're able to search, filter, and perform actions such as voiding/refunding transactions.

You can also create non-ledger transactions from here as well, which are transactions that are not tied to any ledger items.

The layout of the Transaction Log is similar to other nodes in the Accounting Ability. The table will list Transactions in the date range set in the Start Date and End Date. These fields default to today's date.

You can also filter to just see any Non-Ledger Transactions. You can also search for items by using the Search bar. The search bar locates any information in all columns in the current filter configuration. For example, if you search for transactions, and the filter is configured to view today's results, the search will only return any results from today's results.

Double clicking a transaction will take you to that transaction if it's a Ledger Transaction.

The bottom half of the Transaction Log is dedicated to details about the selected Transaction. You'll be able to see the Card Read Method (Manual, Transmit, or Forced), and other details from the card reader.

The Actions Drop down menu will allow you to take certain actions, depending on the transaction selected (if any). The available Actions are:

• Void: This action will attempt to Void the selected transaction. Voiding a transaction will only be successful if the current credit card batch is still open. See Batch Management for further details.
  It is important to note that a voided transaction will not be displayed when looking at a patient's ledger. If you void a transaction, you should immediately navigate to the patient's ledger to address the payment accordingly. We typically recommend refunding the card payment without entering a credit card so the ledger correctly adjusts the balance accordingly, then adding a comment to that refund to document what happened.

• Print Receipt: This action allows you to print a credit card receipt for the selected transaction, as described in Receipts. This method does not create a new Receipt ledger item. This option functions for both patient and insurance credit card payments.

• Go To Transaction: This action will take you to the selected transaction in the appropriate ledger.

• Post as New Patient Payment: This action is used on Non-Ledger Transactions. With a non-ledger transaction selected, you can use this action to post the transaction to a patient's ledger as a new patient payment. You'll be prompted to select the patient you wish to post the payment to. This will allow you to post the payment without having to re-run the credit card transaction.

• Post as New Patient Insurance Payment: This action is used on Non-Ledger Transactions. With a non-ledger transaction selected, you can use this action to post the transaction to a patient's ledger as a new insurance payment. You'll be prompted to select the patient you wish to post the payment to. This will allow you to post the payment without having to re-run the credit card transaction.

• Post as new Bulk Insurance Payment: This action is used on Non-Ledger Transactions. With a non-ledger transaction selected, you can use this action to post the transaction to a bulk insurance payment for an insurance company. You'll be prompted to select the Insurance Company you wish to post the payment to. This will allow you to post the payment without having to re-run the credit card transaction.

• New Non-Ledger Sale: This action is used with no transaction selected. It allows you to run a credit card transaction that is not associated with a ledger patient or insurance payment. You can later post it as a patient/insurance payment with the above "Post as New Payment" actions if you wish. Non Ledger Sales are not reflected on any patient balances and will not appear on reports.

• New Non-Ledger Refund: This action is used with no transaction selected. It allows you to run a credit card transaction that is not associated with a ledger refund. This option should be used sparingly, as a blind credit sent to TSYS without a connected transaction will raise a flag with their risk mitigation team and will likely be subject to review by TSYS. Non Ledger Refunds are not reflected on any patient balances and will not appear on reports.
  Non-Ledger refunds cannot be tied to any ledger items like Non-Ledger Sales can be.

Batch Management

TSYS will provide more information regarding Batches and how they work and their processes, so this section will focus more on the essentials an office must do within MacPractice to appropriately manage their batches.

In the Batch Management node, you're able to pull information from the previous batch, or you can close the current batch for the currently connected card reader device.

TSYS can be configured to automatically close batches every day so long as there was not a problem with closing the batch. If there has been a problem, the batch will not close, and thus all transactions are not finalized and the transaction amounts are not deposited into your account.

In order to manage this properly, MacPractice recommends taking two steps on a daily basis. Be aware that you will need to perform these actions for each connected card reader device.

1. On a daily basis, at the beginning of the day's business, click the "Fetch Data From Previous Batch". This will allow you to verify that the previous batch was closed. By clicking this button, you will be given a summary of the previous batch.

   If the batch was rejected, you won't see a notice by "Time batch closed" and you may see a rejection message. This is an indication that you'll need to reach out to TSYS for assistance on how to resolve the issue.

2. Once you have verified that the previous batch has been closed successfully, you're good to go. TSYS can normally auto-close batches on a daily basis, but if you have opted to manually close batches, you'll need to use the "Close Current Batch" button at the end of the day. By closing a batch, you will no longer be able to void any transactions, and this will finalize those transactions, allowing transaction amounts to be deposited into your accounts.
   If you see a Rejection message, contact TSYS for assistance.

For any questions regarding batches, or any assistance with resolving a batch that cannot close, please contact the TSYS ISV Care Team at (855) 882-0507.

Shifting Payments to Other Accounts

Let's say you accidentally ran a credit card transaction for the wrong account, and wish to post it to the correct account.

In order to accomplish this correction, you'll first need to locate the original payment that has the credit card transaction tied to it. You can either navigate to the patient account if you know it, or you can locate the transaction in the Transaction Log.

Once you've located the payment, you will need to delete it from the incorrect patient's account. You will see a warning that deleting a payment will not void or refund the credit card payment.

By deleting the payment that the transaction is connected to, you will turn this transaction into a Non-Ledger Transaction. These can be located in the Transaction Log.
From there, you can use the Transaction Log Action "Post as New Patient Payment" or the Action "Post as New Patient Insurance Payment". This will create a new payment, either patient or insurance, and the credit card transaction will be tied to this payment.
You will be prompted to select a patient upon selecting this action.

Setting Up an Account's Wallet for Card On File and Recurring Payments

In order to set up recurring payment schedules via Credit Card or ACH Account, or to process credit cards on file, you'll need to set up a Wallet for the patient's account. This is essentially a container for the Account's available payment methods on file.

On the Account Tab in the Patients Ability, we have added a new Tab, the Wallet Tab where the user can add Wallet entries for Credit Cards or ACH Accounts. This can be found in the Patients Ability > Account Tab > Wallet Tab.

Here, you can review the Credit Cards, or ACH Accounts on file in this account's wallet. You can add Credit Cards or ACH Accounts by clicking the Green Plus above the corresponding table you wish to add to. 

 Next, we'll talk about Credit Cards and ACH Accounts separately.

Credit Cards

By clicking the Green Plus above the Credit Cards table, you can add a Credit Card to this account's Wallet. A window will appear where you can enter the card's information.

By double clicking a Credit Card entry, you can edit the Nickname. To adjust any other details such as the card number, you'll need to add a new card as you cannot alter card information once initially entered.

By clicking the Red Minus with a card selected, you can archive that card, removing it from this table and as an option 

Credit Cards added to the account can only be used for Patient Card payments, not Insurance Card payments.

• Cardholder Name: The Cardholder Name as it appears on the card in question. This is not a required field by the software, but we strongly recommend completing this field.

• Card Nickname: A user-defined Nickname for this card. This has no impact on whether a card will process, and is merely used as a reference. For example, you could add a Nickname of "Mom's card" if the Credit Card belongs to the mother on the account. 

• Card Number: Required. The number of the credit card in question.

• CVV: The 3 or 4 digit CVV code on the Card in question.

• Expiration Date: Required. The Expiration Date of the credit card in question.

• Street Address: Required. The Street Address associated with the credit card in question.

• Zip Code: Required. The Zip Code associated with the credit card in question.

• Set as Default Credit Card checkbox: Allows you to set the default credit card that will be used for this account.

Once a card is on file, you will then have an option available in the ledger when posting a new card payment to utilize a Card on File in the "Card Entry Method" drop down menu, located in the upper right hand corner of the Payment Window:

When selected, an additional drop down menu will appear below the Card Entry Method menu which will allow you to either select one of the cards that are on file in this account, or you can add a new one on the fly.

ACH Accounts

ACH Accounts are used to set up Recurring Payments. These accounts can only be used for Recurring Payment Plans and not one time payments.

By clicking the Green Plus, you can add an ACH account. A window will appear where you can enter the account's information. You'll need to provide:

• Name on Account: The name on the bank account in question. This is not strictly required but it is best practice to include the name.

• Account Nickname: A user-defined name for this account for reference. It is not a required field and will not impact processing of payments.

• Routing Number: Required. The routing number of the bank account in question. This can either be obtained from the patient's bank or at the bottom of a check for the account in question.

• Account Number: Required. The account number of the bank account in question. This can either be obtained from the patient's bank or at the bottom of a check for the account in question.

• Street Address: Required. The Street Address associated with the bank account in question.

• Zip Code: Required. The Zip Code associated with the bank account in question.

• Set as Default ACH Account checkbox:  Allows you to set this account as the default ACH Account that will be used when setting up a Recurring Payment.

Recurring Payments

On the Account Tab in the Patients Ability, we have a new sub-tab called Recurring Payment Plans. This is where you can add and discontinue an Account's payment plans.

An Account can only have one Active Plan at any given time. If you want to activate a second Recurring Payment Plan, you must discontinue the currently Active Plan.

In the Actions pull down, we have a number of options that will assist clients in managing Recurring Payment Plans on an Account. 

• Open Recurring Payment Plan: This option allows you to open up an existing Recurring Payment Plan. You can edit the Payment Type associated with new plan payments, or the reference number by doing this, but cannot edit other details.

• Discontinue Recurring Payment Plan: This option allows you to discontinue a Recurring Payment Plan if it is no longer necessary or you need to adjust the Recurring Payment Plan, as you cannot edit them once created.

• New Recurring Payment Plan: This option allows you to create a new Recurring Payment Plan that can use either a Card on File or an ACH Account from the Account's Wallet.

• Go to Recurring Payments Manager: This option will take you to the Recurring Payments Manager, located in the Accounting Ability.

To create a new Recurring Payment Plan, users will go to the Actions pull down and click New Recurring Payment Plan. This will bring up the Recurring Payment Plan window.

The Created Date will be today's date, and uneditable. The First Payment Date will default to today's date and can be changed to another date.

Next, you'll want to select the Payment Type to be used for incoming recurring payments. These will pull from the Payment Types defined in your References Ability.

You can also enter a reference number, much like the Reference Number field in the Payment Window of the Ledger when creating a new Payment.

Then, you'll click on the Credit Card or ACH Account Tab to select the method of payment as shown in the below screenshot. Once you have clicked the Credit Card or ACH Account tab, you'll be able to then select the Card or ACH Account you wish to use for this Recurring Payment in the Account drop down selector.

If only one account is entered in the Accounts Tab > Wallets for either Credit Card or ACH Account, it will be the only option available to choose on that tab.

Once an account has been selected, the user will enter the total amount of the Payment Plan and select to calculate the Payment Schedule based on a specific payment amount or number of payments.

Next, you'll choose the Frequency which the payments will be deducted from the patient’s card or ACH account. The options that can be chosen for a payment schedule are Weekly, Every Other Week, Twice Per Month (1st/15th), Monthly, Yearly, Weekly - Custom and Monthly - Custom.

Weekly - Custom will allow the user to specify the day of the week that the user would like to have the payments processed on. Multiple days can also be selected here each week.

Monthly - Custom will allow the user to specify which months to process the payments over the course of the year(s).

Once you have filled in all required information and set the desired frequency, you'll click the Calculate Payment Schedule button to populate the information in the Payment Schedule Panel.

When calculating the final payment, keep in mind that not all schedules will have even amounts. There could be instances where final payments are pennies while other final payments are remainders of the amount left. In MacPractice, we will handle final payment calculations in a couple of ways depending on whether you have selected a specific number of payments vs. a specific payment amount:

If you select a specific number of payments, we will add the remainder of the total payment amount to the last payment amount. 

• Example: If a user has a $100 total broken out into 3 payments, the first two payments will calculate to 33.33 and the final payment will be 33.34.

If you select a specific payment amount until it is paid off, we will ensure that the last payment is not more than the payment amount - we will add another payment to the plan to process this payment. 

• Example: If a user has a $100 total broken out into payments of 33.33, the first three payments will be 33.33 (equaling a total of 99.99) and a final payment of .01

You can also print the Payment Schedule by pressing Command-P on your keyboard. This will simply print the payment schedule as it appears on the right panel, but this functionality will change in the future.

Once a Recurring Payment Plan has been completed, MacPractice will check every hour to determine if a Recurring Payment needs to be issued based on the schedule.

Recurring Payments will be posted onto the Account's ledger, viewable on all patients on the account as an unapplied payment with "Recurring", the Reference Number you set when creating the Recurring Payment Plan, and the amount of the payment in the description of the payment.

Recurring Payments cannot be voided or refunded if they are part of an Active Recurring Payment Plan. The Payment Plan MUST be discontinued prior to voiding or refunding payments.

Recurring Payment Manager

 In the Accounting Ability under the Card Transactions node, we have added a new manager called Recurring Payments Manager. You can also navigate to the Recurring Payments Manager from within the Actions pull down in the Recurring Payment Plans sub-tab in the Account Tab of the Patients Ability.

You can filter recurring payments received by the posted date of the payment - the posted date of the payment is the date the payment is received from TSYS in MacPractice.

You can also filter by the status of the payment - All Payments, Fully Applied Payments, Partially Applied Payments and Unapplied Payments. You can populate these results by clicking the Apply button. This is useful to ensure that all your received payments have been applied appropriately.

When a payment is selected within this Manager, you can interact with the payments in the Actions menu. You can print a receipt, go to the payment in the Ledger and go to the account to interact with the plan and Wallet. Double clicking on the payment will also take them to the payment in the Ledger.

In the table view of the Recurring Payments Manager, there are a number of columns that display for each payment. The table can be sorted by any of these columns.

• Status: This column displays whether a payment has been applied, partially applied or is currently unapplied.

• Has Refund: This column indicates with Yes or No that a refund has or has not been associated with this payment.

• Account: This column displays the account number that the payment is associated with.

• Primary: This column displays the Primary Account name on the account.

• Posted Date: This column displays the date the recurring payment was posted (corresponds to the date received from TSYS). This could be different from the processed date if the server has been off for a couple of days).

• Applied Date: This column displays the posted date or the date that the payment was partially/fully applied on the account.

• Description: This column displays the description of the payment from the ledger.

• Payment Amount: This column displays the processed payment amount. If a payment was partially approved, this will show a lower amount than what is in the plan. Users will need to communicate with the patient to satisfy the remainder of a payment if it is less than expected from the plan.

• Applied Amount: This column displays the amount applied on the payment. If the payment is fully unapplied, it will display $0.00.

• Pr/Of: This column displays the Provider/Office the payment is tied to. It will display nothing if it is unapplied though a Provider/Office can be set without applying the payment.

• Last Edited By: This column displays the user that last edited the payment.

Declined/Partial Approved Recurring Payments

Declined recurring payments do NOT display in MacPractice. The merchant will receive an email from TSYS if a recurring payment is declined and they will need to use it in conjunction with the Merchant Center to identify which account this payment belongs to. MacPractice does not have a way to check TSYS for declined recurring payments. From here you'll will need to reach out to the patient to satisfy the missed payment. 

Clients will receive an email from TSYS when a card is declined or if an amount was partially approved. The Customer ID in the email will correspond with the Account ID in MacPractice. When a client receives this email, they will want to go into MacPractice to review the recurring schedule and reach out to the patient to satisfy the declined/partially approved amount.

Declined payments are not taken into consideration when the Recurring Payment Plan on the account decrements the Remaining Amount on the plan. Remaining amount is calculated based on the expected date of the payment. Users will need to post new payments in the Ledger unassociated with the payment plan when funds are recouped from the patient.

Online Patient Payments

Online Patient Payments is a new feature included in MacPractice Build 12.21. You can learn more about this feature in this linked article.

Common Error Messages

We never want to see error messages, but they do provide us information regarding any problems we may be facing. This section can help you interpret what these error messages mean. If you are EVER in doubt, contact MacPractice Support and we can assist you.

Common MacPractice Errors

• Unable to parse response from device

  • Device has sent a response that MacPractice does not expect or is garbled.

• Invalid response received from device

  • Device has sent a response that MacPractice does not expect or is garbled.

• Machine Identifier Missing

  • UUID is somehow missing

These three errors above have to do with the communication being received from the PAX Device. This may indicate a faulty connection or a malfunctioning PAX Device. Troubleshooting steps could include unplugging the PAX Card Reader and re-plugging it in (both power and ethernet connection) and reconnecting the PAX Card Reader via the TSYS Preferences and Setup instructions. If problems persist, please contact TSYS for further information.

• Unable to save (card receipt) to database

  • Unable to save something to the database usually means that there is an connection issue between MacPractice client and MacPractice Server and/or database.

• Unable to create ledger item

  • Unable to create something in the database usually means that there is an connection issue between MacPractice client and MacPractice Server and/or database.

• Unable to connect to database to (retrieve connection time, update PAX device connection)

  • Unable to connect to the database usually means that there is an connection issue between MacPractice client and MacPractice Server and/or database.

• Unable to retrieve (connection time, card selection type) from database

  • Unable to retrieve information from the database usually means that there is an connection issue between MacPractice client and MacPractice Server and/or database.

For the above errors, the common thread between them all is a connection problem between a MacPractice Client computer and the MacPractice Server computer. Troubleshooting steps would include confirming the computer you're using is connected to your network, checking to ensure the Server Computer is running with MacPractice started, and restarting your Server and Client computers.

PAX Card Reader Messages

The following table describes errors and messages that the PAX Card Reader itself will produce in various situations. For more detail on some of these issues, please contact TSYS Support.