Payment Testing

If you are a patient looking to make a payment, please click here to Make a Payment or contact your provider.



Credit card transactions are a major component of any payment collection features in athenaNet, and API users should thoroughly test their applications for compatibility with athenahealth’s APIs for processing credit card-related transactions. This document guides API users in helping ensure that both practices and API users have a successful experience in utilizing the credit card APIs. Basic functionality covers all aspects of the API not involving contract setup. A separate section below covers contract testing.


By using the POST /patients/{patientid}/recordpayment endpoint, you may record payments via API (see Record Payment). In order to support recording non-CCP credit card payments via API, we introduce the following new API.

This API retrieves a list of valid, non-deleted credit card methods that have been configured at a practice level so the API user can determine which credit card payment methods are valid for a practice. 

The following criteria can optionally be supplied when calling this new endpoint:

  • limit - the number of entries to return (default 1500, max 5000)
  • offset - the starting point of entries; 0-indexed

    Output fields include paired combinations of name and paymentmethod.  API users will supply the paymentmethod value when calling 

    Sample Data:

    • "name" : "American Express",
    • "paymentmethod" : "AMEX"


    NOTE: This page is a summary of payment testing. More detailed information is available for users whose companies have signed a non-disclosure agreement (NDA) with athenahealth.

    Normal Transactions

    Validation of the basic functionality entails performing a series of tests to make sure that your solution is working properly with athenaNet. Each of the following should be performed separately with a VISA and an AMEX card (even if the practice does not support AMEX, in which case the purchase should fail gracefully). If possible, separate testing with one of each of the other two types of major cards (DISC/MC) is also encouraged.

    Perform a standard keyed & swipe purchase with the card on a test patient, typically with a small amount, such as $0.05. Note: Swipe purchases cannot easily be tested in preview unless you have a dummy test card from some source (see note below about which test cards should be used in which environments). In the preview environment, you may use the following test card data:

    Card Type:


    Card #

    4000 0000 0000 0002 

     and 4012 8888 8888 1881

    Expiration Date 12/22
    Dollar amount Must end in .00, ex: 40.00 but not 40.32


    Card # 5121 2121 2121 2124 
    Expiration Date 12/22
    Dollas amount Must end in .00, ex: 40.00 but not 40.32


    Card #

    6011 0000 0000 0004

    Expiration Date 12/22
    Dollar amount Must end in .00, ex: 40.00 but not 40.32

    American Express

    Card # 371449635398431
    Expiration Date 12/22
    Dollar amount Must end in .00, ex: 40.00 but not 40.32


    You may use the following sample track data.
    Be careful with URL encoding since the initial % in the data needs to become %25:
    Card Type:


    Sample Track Data %B4124939999999990^TEST/TESTCARD^19129015432139614567891234567890?;4124939999999990=191290154321396145?
    Track 1 Length 70
    Track 2 Length 35



    Sample Track Data


    Track 1 Length 76
    Track 2 Length 37



    Sample Track Data %B6011013333333331^TEST/TESTCARD^19129015432139614567891234567890011223?;6011013333333331=19129015432139614567?
    Track 1 Length 76
    Track 2 Length 37


    American Express

    Sample Track Data %B370000999999990^TEST/TESTCARD^19129015432139614567891234567890011223?;370000999999990=19129015432139614567?
    Track 1 Length 75
    Track 2 Length 36


    Important Notes:

    1. Ensure that your application …
      1. Retrieves a receipt from athenaNet for the transaction.
      2. Asks the patient to sign it digitally.
      3. Returns the signed PDF copy to athenaNet (via the API).
    2. Ensure the receipt can be viewed in the athenaNet UI.
    3. Ensure the payment processed successfully and was posted properly via athenaNet UI.
    4. Void the transaction in athenaNet (thereby refunding your card, if using a real one in production).

    Dos and Don’ts

    Please do:

    • Test your solution in the preview environment (/preview1/) before moving to testing in our production environment (/v1).
    • Aggressively test edge cases (preferably in preview first), such as network connection loss mid-transaction, or mid-workflow. 
    • Perform any additional tests beyond the basics that you feel necessary for your solution.
    • Engage directly with your early rollout practices to help ensure successful testing. You may need their help in performing some validation testing in production. Explain to them that this testing may incur minor extra credit card transaction fees (per transaction). 

    Please do NOT:

    • Use any "test cards" you may have from credit card processors (or other sources) in our production environment. 
    • Use any real credit cards in the preview environment. This environment is not PCI-secure.

    NOTE: The following is a table showing which types of cards should be tested in which environments:

    Card Type



    Test cards


    Do not use

    athenahealth-provided keyed card numbers


    Do not use

    Real credit cards

    Do not use



    Error/Exception Handling

    In addition to testing the basic functionality, API users should also check to ensure that their solution correctly handles error messages and situations. Some of the most common situations are listed below, with testing suggestions.  

    Note: The below list is not comprehensive since the responses can be different depending on card brands, processers/gateways, etc.  API users should take a "black box" approach when testing their solution.

    Transaction Declined: A transaction can be declined for various reasons, including an invalid credit card number and/or expiration dates. API users should test these cases to make sure their system responds appropriately. Some of these responses can be simulated in the test environment by entering certain amounts. We suggest using these amounts in preview only:

    -$1.05 – Will produce a DECLINED response for all card types

    -$1.12 – Will produce a CALL AUTH CENTER response for all card types

    -$1.14 – Will produce an INVALID CARD response for all card types except DISC (which returns CALL AUTH CENTER)

    -$1.33 – Will produce an EXPIRED CARD response for all card types except DISC (which returns CALL AUTH CENTER)

    Transaction Timeouts:  This class of error indicates a connection breakdown, either of the API user-to-athena type or of the athena-to-Transaction Processor type.

    The former situation can be simulated easily by “pulling the plug” on the device’s internet connection mid-transaction (preferably in athenaNet’s preview environment).

    In the latter case your application would expect to receive an error response that says “Gateway Timeout”. It is not currently possible to test this timeout mode in our preview environment.

    Additional VISA codes for testing: Please reference the codes below for VISA card testing. For example, if you were to submit a $1.00 amount, it will produce an APPROVAL response for VISA card types.  


    Authorization Response


















    Note: When testing the functionality in a preview environment you may receive the error: 

    Error: There is no valid terminal ID associated with this department.

    If you receive this error when testing in a dedicated preview environment, please work with your athenahealth technical resource to resolve this issue.  

    Was this information helpful? Yes | No Thank you for your feedback! What went wrong? Incomplete or incorrect information | Irrelevant Content | Others