Developer Resource Center

Developer Documents


Welcome to the EdgePay Developer Resource. Below is an overview of each of our APIs, interfaces, and some fundamental payments considerations. If you need help, use the links below to our technical resources that are ready to assist you on your journey. Please familiarize yourself with the tools to help you decide what would be the best combination for your project. As always, feel free to connect with our Developer Support Team if you have any questions.

Developer Support: Phone Email


API Payment Processing

Enable server to serve payments for all transaction types

More info

BatchPay Payment Processing

Upload a file of payment transactions and we will process and return you the results

More info

Hosted Pay Page

Your pay button calls our pay page that you customize

More info

Virtual Terminal

Using your processing center portal your team enters payments via a browser

More info

eCommerce Plugins

Use one of our certified shopping cart plugins to process payments

More info

Security and Risk

Fraud Management Service

Set up static, dynamic, or machine learning filters and capture results

More info

Token Service

Replace sensitive credit card or checking account info with a token you can safely store

More info


Exchange credit card data for a token in-session from browser back to your server

More info


Verify card/cardholder info for card-not-present customers

More info

Subscription and Recurring Payments

Recurring Payment Manager

Set up products or services with payment schedules, add customers--we do the rest

More info

Account Updater Services

Enroll in our Account Updater Service and keep your cards on file fresh

More info

Data Intelligence


Check on your most recent payment activities using the EdgePay dashboard

More info


Use our online reporting to access critical info in real-time or set up to receive files for your system

More info

Machine Learning

Use your customer interactions to make business decisions

More info

EdgePay SDLC Process

Before you begin

Topic Discussion
AUTHORIZE AND CAPTURE OR SALE (CAPTURE TOO) The credit card system is a 2-message system, with authorization preceding capture. Money only moves after capture. There are some good reasons for a 2-message system like tip adjust (final amount is less than or greater than the authorized amount), or if you ship your goods or deliver your services after the authorization date and time. But, if everything happens all at once, consider a sale payment that will automatically capture the transaction for you.
TOKENIZATION Do you want to store credit card or banking information on your server? If not, consider using one of our token services. You can request a token separately via the API, or as part of the payment request. One-time tokens can be requested via the Pivot API. Also, tokens can be requested or managed in the processing center.
VERIFICATION ONLY Sometimes verifying a card by using the address verification service (AVS only) or the security code (CVV or CVV2) may be helpful for some businesses. These are zero-amount services transactions but confirm that the person supplying the payment also knows the cardholder zip code and/or security code. ACS and CVV are also typically used on card-not-present payment transactions to verify the card is valid.
DON'T KNOW THE FINAL AMOUNT YET Sometimes the final amount cannot be determined at authorization. You can adjust the final amount with a capture transaction and an adjust code specifying the new amount and tip and/or tax if applicable.
AVOID TRANSMITTING CARD DATA If you want to avoid processing card data, consider Pivot. This API/Interface uses the customer's browser or even an employer browser and replaces the credit card with a 1-time token.
SPECIAL DATA NEEDS FOR CERTAIN BUSINESSES OR TRANSACTION Some businesses and, in certain circumstances, transactions will benefit from more data. The additional data can improve interchange and reduce costs. Also, some card-issuing banks may require more data for card not present transactions. Below are some examples where more data may be required:
  • eCommerce or Keyed Transactions: eCommerce, mail order, telephone order transactions require billing zip and will cost less if you add billing address, billing city, billing state, and CVV code
  • Recurring Transactions: If a transaction is recurring, such as a monthly membership, use the recurring action code and supporting fields to optimize approval rates and interchange
  • Healthcare Transactions: If you take FSA or HSA credit cards (health savings accounts), then use the healthcare action code and supporting fields
  • Level 2: If you accept business credit cards or purchasing cards, you can include the tax amount and your purchase order number and reduce interchange expense by up to 1/2% for those payments
  • Level 3: Much like Level 2, Level 3 will save even more on interchange for some business-to-business transactions. The amount of data required for Level 3 is much greater and is typically reserved for "system-to-system" interfaces
  • Tips and Tip Adjust: If your business takes tips, use the "authorization, then capture" strategy and adjust the amount in the capture transaction 

Start building now!