View the Project on GitHub PineapplePayments/pineapple-developer-center
Part 1 of this guide is intended to enable the Pineapple Payments operations and sales teams, Reseller Agents, and ISV Integrators to successfully demo, test, and integrate with Transax. Pineapple Payments are the creators of Transax, and partner with orgnizations around the country to bring Transax to users.
Part 2 of this guide covers Going Live.
Roles and terminology in the Payments space can be confusing. This guide uses the following meanings.
By the end of this chapter, you will have a Merchant User that you can use for Testing and Demo purposes.
This Test Merchant User can be used for most Transax features, including the Virtual Terminal, Recurring Billing, SAFE, Invoice Management, Quickbooks Desktop Plugins, Hosted Payment Pages, and Mobile Apps. Other chapters in this guide cover how to get strated with specific advanced Transax features such as Dip in Browser, Salesforce plugins, Quickbooks Online Plugins, API Integrations, and EMV Integrations.
The Pineapple Payments Partner Team is responsible for providing an Agent account in Transax for each Payments Sales Agent or Reseller that contracts directly with Pineapple Payments. Payments Sales Agents other than Pineapple Payments are responsible for creating Agent accounts in Transax for any Payments Sales Agents or Resellers that contract with them directly.
Every Payments Sales Agent and Reseller needs their own Agent account in Transax, even for Demo or Testing purposes. There is no downside to creating new Agent accounts early in a potential relationship, and it may lead to additional self-discovery of valuable Transax features by the Agent.
In this step, you’ll be creating a real Agent account - not a Test account. This Agent account will be the one utilized for both Test and Production merchants.
To create a new Agent in Transax:
Once you’ve confirmed the Admin User is able to log in, you can move onto Step 2.
NOTE: The Admin user can add additional individuals from their organization to this Agent account. This should be done if more than one person needs to use an account; the same username and password should not be shared by multiple individuals.
In order to process payments, including for Demo or Test purposes, a Merchant and one or more Merchant Users must exist within Transax.
The Payment Sales Agent or Reseller that conducts Demo or Test activities (for themselves or for a prospective Merchant) is responsible for setting up the Merchant Test Account.
As a general rule, you should never share usernames and passwords to Transax for any reason. Instead, use the built in user management features to set up Users for each individual and organization that needs to login, so they obtain their own account number, username, and password.
In the following steps, we will set up a Test merchant. Test Merchants cannot process real payments, and real cardholder data should not be entered when using a Test merchant. Transactions less than $1.00 will decline, and above $1.00 will approve. When ready, see Part 2 for more on Going Live.
4111 1111 1111 1111
and any future expiration date. Since this is a test account, fake billing information is acceptable.The Merchant User created in the above steps is now ready to be used for Demos and Testing.
When you login as the Merchant User, you can utilize standard Transax features including the Virtual Terminal, Recurring Billing, SAFE, Invoice Management, Quickbooks Desktop Plugins, Hosted Payment Pages, and Mobile Apps. Using that Merchant User account, you can change configurations to customize the demo for your particular use case. Additionally, you can log in with your Agent User account number, username, and password to search for the Merchant to update certain configurations such as Processors if needed for your particular demo and test purposes.
REMEMBER Test Merchants cannot process real payments, and real cardholder data should not be entered when using a Test merchant. Transactions less than $1.00 will decline, and above $1.00 will approve. Configurations and data setup in a Test merchant are NOT transferable to Production Merchants. When ready, see Part 2 for more on Going Live.
Potential Next Steps:
By the end of this chapter, you will have a test Merchant User and the necessary username and password for beginning an API Integration with Transax Rox APIs.
This test Merchant User can be used to integrate to Transax using the ROX APIs, including for Transactions, Hosted Payment Pages, Recurring Billing, and Invoice Manager. Refer to Chapter 3 for specific advanced Transax integrations involving EMV.
Before doing the following, you should have completed the steps in Chapter 1: Getting Started with Transax.
It is a best practice to create a separate user account for interacting with the Transax APIs. While not strictly required for integration development and testing purposes (you can use the merchant username and password created in Chapter 1, Step 2), doing so ensures assumptions are not being made about user credentials and permissions.
CompanyName_API
. Make sure to set a unique password that you remember - it will be needed to authenticate with the API.Access API
checkbox. This should be the only box checked. Then select Save.The user created in Step 1 can then be used with the Transax API. Whenever you see a username
and password
field in API requests, substitute the values set up in Step 1. These values should be stored securely within your application. If you ever need to update the password, you can use this username and password to login to the Transax portal and change the password as if it were a real and not just an API user. Finally, note that APIKey
and AccountName
may appear in examples and documentation, but they are not necessary in any API calls.
REMEMBER Test Merchants cannot process real payments, and real cardholder data should not be entered when using a Test merchant. Transactions less than $1.00 will decline, and above $1.00 will approve. Configurations and data setup in a Test merchant are NOT transferable to Production Merchants. When ready, see Part 2 for more on Going Live.
Potential Next Steps:
By the end of this chapter, you will have a test Mechant User that can demonstrate and test EMV Dip In Browser with the IDTECH Augusta desktop EMV device.
Before doing the following, you should have completed the steps in Chapter 1: Getting Started with Transax.
You must use an Augusta device obtained through the link below. Legacy devices or devices not keyed for Transax are not elibile for use with this feature.
IDTECH AUGUSTA
.You will receive an email confirmation, and the device will ship within two days.
This device can be used for both Demos/Testing and, when ready, Production transactions.
TSYS is the only supported processor for Dip in Browser. Additionally, there must be two terminals setup under Processors in Transax for Dip in Browser to work. In this step, you will setup a test merchant to use Dip in Browser - this is equivalent of, when ready for production, setting up a merchant using two VAR sheets.
You are now able to use the Dip in Browser feature. Plug in the Augusta device and visit the Virtual Terminal. When you select the processor added above, the Dip button will appear.
Potential Next Steps:
By the end of this chapter, you will have a Merchant User and the necessary username and password for beginning an API Integration with Transax Rox APIs for EMV Integration use cases.
Integrating for EMV differes from other integrations because to successfully validate payloads they must be sent through to processors and issuers. For this reason, EMV Integration happens against Production merchant accounts. If you’ve already followed the steps laid out in Chapter 1, you must complete the steps in this chapter also.
If you do not already have one, work with your Payments Sales Agent to submit a TSYS merchant account application for your business. Only TSYS Sierra (aka Broomfield) accounts are EMV eligible at this time.
Upon account approval, request two Generic TSYS Sierra VAR Sheets. You can do so through your Payments Sales Agent, who should have access to the TSYS ELAPP system or can contact TSYS ISO Support services.
If you already ahve a Merchant Account with TSYS, just request two new VAR sheets.
You must obtain a device that is keyed and supported by Transax. Only the following devices are supported:
If your use case calls for the Augusta, then obtain a device through the link below. For other device types, contact your Payments Sales Agent for assistance.
IDTECH AUGUSTA
.You will receive an email confirmation, and the device will ship within two days.
In the following steps, we will board the merchant account obtained in Step 1.
Once you log in, we suggest running a test transaction from the Virtual Terminal to ensure that the merchant was setup correctly.
It is a best practice to create a separate user account for interacting with the Transax APIs.
CompanyName_API
. Make sure to set a unique password that you remember - it will be needed to authenticate with the API.Access API
checkbox. This should be the only box checked. Then select Save.You are now ready to begin an integration with EMV.
Potential Next Steps: