Follow

PayJunction Account Structures

For applications looking to support multiple terminals for merchants with multiple locations or franchises, it is important to understand how PayJunction accounts are structured.

MID vs PJMID

While these terms are not as important for understanding and using the API, it is important for understanding how accounts are structured in PayJunction. PayJunction processes its merchants' transactions through a processing company, which assigns a Merchant ID (MID) for each Merchant Account. PayJunction also assigns its own unique ID, the PayJunction Merchant ID (PJMID) for each merchant. A PJMID will have at least one MID attached to it, but can potentially have many.

TIP: The following does not apply to billing and fees for an account, only the logical structure for purposes of using the API.

All the data for an account, including login credentials, API connections, transaction and customer history, etc. is tied to the PayJunction account (PJMID). Because this information is specifically tied to the PJMID, PayJunction can swap out Merchant Numbers (MIDs) and terminals while leaving all other data in place. Any of the following reasons can trigger a swap out of MIDs and terminals:

  • A business restructures itself (ex. A business restructures itself from a Sole Proprietorship to a Limited Liability Company).
  • Change of Ownership for a business.
  • IRS Mismatch of legal name and/or federal tax ID requires a new MID.

Therefore it is highly recommended to never hardcode the ids for terminals or Smart Terminals and instead to use GET /terminals and GET /smartterminals to retrieve these ids to prevent PayJunction maintenance work from breaking the integration.

Example Account Structures

SINGLE PAYJUNCTION ACCOUNT, SINGLE MERCHANT ACCOUNT, SINGLE TERMINAL (Basic Setup)

DBA: XYZ Car Sales
PJMID: 123456
API Login: api@xyzcarsales.com
MID: 00000001
Terminal

  • TID: 654321
  • Nickname: "XYZ Car Sales"

For the above example, there are no special considerations in regards to the API. As there is only one terminal, all transactions not processed through a Smart Terminal will default to this terminal and we only need to know the terminal's id for sending payment requests to a Smart Terminal.

SINGLE PAYJUNCTION ACCOUNT, SINGLE MERCHANT ACCOUNT, MULTIPLE TERMINALS

If our example business decides to add an additional terminal to separate the transactions for the sales department from the service department, here's how the PayJunction account structure will look.

DBA: XYZ Car Sales
PJMID: 123456
API Login: api@xyzcarsales.com
MID: 00000001
Terminals
  • TID: 654321, Nickname: "Sales"
  • TID: 655798, Nickname: "Service"

If we want to support this for the merchant, we must now send the terminal id to process through for each transaction request, regardless of whether it is being processed through a Smart Terminal.

SINGLE PAYJUNCTION ACCOUNT, MULTIPLE MERCHANT ACCOUNTS, MULTIPLE TERMINALS

Our example merchant is doing very well, and decides to open a new location. In order to access both accounts from one set of login credentials, the merchant decides to attach another MID to the existing PayJunction account and PJMID. Here's how the PayJunction account structure will look.

DBA: XYZ Car Sales
PJMID: 123456
API Login: api@xyzcarsales.com
MID for LA location: 00000001
MID for SF location: 00000005
Terminals for LA, MID 00000001
  • TID: 654321, Nickname: "LA - Sales"
  • TID: 655798, Nickname: "LA - Service"
Terminals for SF, MID 00000005
  • TID: 656991, Nickname: "SF - Sales"
  • TID: 656992, Nickname: "SF - Service"

Even though we now technically have two merchant accounts, they are all accessible via one set of API credentials and can be referenced in the API by their unique terminal id values.

MULTIPLE PAYJUNCTION ACCOUNTS, MULTIPLE MERCHANT ACCOUNTS, MULTIPLE TERMINALS

Having grown their brand name, our example merchant decides to open a franchise on the East Coast. However, they don't want the franchise owner to have access to the bank deposit and merchant statement information for the West Coast account, so they open a separate PayJunction account:

DBA: XYZ Car Sales
PJMID: 123456
API Login: api@xyzcarsales.com
MID for LA location: 00000001
MID for SF location: 00000005
Terminals for LA, MID 00000001
  • TID: 654321, Nickname: "LA - Sales"
  • TID: 655798, Nickname: "LA - Service"
Terminals for SF, MID 00000005
  • TID: 656991, Nickname: "SF - Sales"
  • TID: 656992, Nickname: "SF - Service"
DBA: XYZ Car Sales East
PJMID: 123481
API Login: api-east@xyzcarsales.com
MID for NYC location: 00000011
MID for Albany location: 00000014
Terminals for NYC, MID 00000011
  • TID: 658111, Nickname: "NYC - Sales"
  • TID: 658113, Nickname: "NYC - Service"
Terminals for Albany, MID 00000014
  • TID: 658245, Nickname: "Albany - Sales"
  • TID: 658246, Nickname: "Albany - Service"

In this scenario, api@xyzcarsales.com can access the terminals and data for the LA and SF terminals, but not the NYC and Albany terminals. This handy support article explains how to create additional API Credentials. Additionally, make sure to restrict terminal access for each API Credential as explained in the support article.