The short answer
A VAR sheet is the set of merchant account settings that someone needs to point a terminal, POS system or payment gateway at the right account. It's commonly called a VAR sheet because the people who ask for it are often value-added resellers (VARs): the companies that sell and set up payment software and hardware.
- What's on it: account identifiers such as the Merchant ID (MID), Terminal ID (TID), bank and routing numbers, and the merchant category code (MCC). The exact fields vary by processor.
- Where it comes from: your merchant account provider or processor.
- What it isn't: cardholder data. It holds no card numbers, but it does identify your account, so share it only with the vendor doing the setup.
What VAR Means in Credit Card Processing
In credit card processing, a VAR is a value-added reseller. It's a company that sells something businesses use to take payments, such as a POS system, practice software, a shopping cart or card terminals, and adds its own setup and support on top.
A VAR usually doesn't provide the merchant account itself. The merchant account comes from a bank or its provider. So before the VAR's product can send a single payment, it needs the details of that account. The sheet those details arrive on is what the industry calls a VAR sheet.
You'll also see "VAR" used for the partners of a merchant services company, as in "VAR merchant services" or a VAR program. That's a different use of the word: it describes how a partner works with a provider, not a setup document. If that's what you're looking into, see ISO vs agent vs referral partner.
One caution: "VAR sheet" is industry shorthand, not a standard form. We didn't find a processor that publishes a document by that name. You may also hear it called a setup sheet or a parameter sheet.
What's on a VAR Sheet: Fields and What They Mean
There's no universal field list. Fields vary by processor, and even by the software being set up. The table below uses one real example: the TSYS fields that Cybersource's developer documentation asks for when adding TSYS card processing (checked September 30, 2026).
| Field | What it is | Who uses it |
|---|---|---|
| Merchant ID (MID) | The number that identifies the business's merchant account at the processor | Every terminal, POS and gateway setup |
| Terminal ID (TID) | Identifies one terminal or connection under that merchant account. One account can have several | Terminals, POS systems, gateways |
| Bank Number and Merchant BIN | Numbers that identify the acquiring bank behind the account, so transactions route to the right bank | Whoever enters the processor settings |
| Chain Number, Store ID, Location Number | Place the account in the processor's structure, for example which chain and which store or location it belongs to | Multi-location businesses and their software vendor |
| Merchant "V" Number | A TSYS-specific merchant number, separate from the MID | TSYS setups only |
| Industry Code | A processor setting for the type of business or sales channel. Your processor supplies the value | Terminal and gateway configuration |
| Merchant category code (MCC) | A four-digit code that classifies the type of business | Cybersource asks for it in its common settings, alongside the merchant descriptor |
Other processors use other names, and some need far fewer fields. A few plain definitions help when you read any version:
- Processor: the company that handles the transaction behind the scenes for the acquiring bank.
- Acquiring bank: the bank that holds the merchant account, pays the business and handles chargebacks.
- BIN: short for Bank Identification Number. On a VAR sheet, it points to the acquiring bank, not to a customer's card.
Who Needs a VAR Sheet, and When
The request usually comes from whoever is connecting the payment side of a system. Common cases:
- POS and software vendors. A restaurant POS, salon booking system or practice management tool that takes cards needs to know which merchant account to send payments to. This is where VAR merchant services and VAR sheets overlap: the vendor sells the software, the merchant account comes from someone else.
- Terminal setup. A standalone card terminal has to be programmed with the account's details before it can run a sale.
- Developers setting up a gateway. A payment gateway sends online payments to the processor. The gateway account has to be linked to the merchant account first.
- Switching processors. A new merchant account means new details, so every terminal, POS and gateway has to be pointed at the new account. Our guide to switching merchant services covers the full checklist, including what happens to your gateway.
The timing matters. Plan for the setup details after the merchant account is approved and before the go-live date. If a vendor can't start until they have the details, ask them early which fields they need, and send that list to your provider.
How It Works When START Sets Up the Merchant Account
For Authorize.Net and Cybersource, the handoff is done for you. Both gateways refer merchants to START. START shops the right merchant account for each business, underwrites it, and then sends the merchant account details to Authorize.Net or Cybersource so the gateway is connected.
For Authorize.Net, most merchants are approved in 1 to 5 business days, and the gateway is set up within 24 business hours of approval.
Connecting other software, such as a POS system or a card terminal? Tell us which software you're connecting, and we'll tell you what the merchant account needs to provide.
If you're a developer, agency or software company that sets this up for clients regularly, our merchant services reseller program explains how partners work with START.
Is a VAR Sheet Confidential? Keeping It Safe
A VAR sheet doesn't contain cardholder data: no card numbers, no expiry dates, no security codes. But it does contain the identifiers for your merchant account. Treat it the way you'd treat a bank account number.
- Share it only with the vendor or developer doing the setup.
- Send it privately, not in a public forum, a shared chat channel or a code repository.
- If you change vendors, ask your provider whether any settings should be updated.
- Be wary of anyone who asks for customer card numbers or your online banking login as part of "setup." Neither belongs on a VAR sheet.
General payments guidance, not legal, tax or accounting advice. "VAR sheet" is industry usage, not a term defined by a processor, and fields vary by processor. The TSYS field list is from Cybersource's developer documentation and the Authorize.Net settings are from Authorize.Net's help pages, both as of September 2026.
VAR Sheet FAQ
How do I get a VAR sheet?
Ask your merchant account provider or processor. First, ask the vendor doing the setup which fields they need, then send that list to your provider so you get everything in one go.
Is a VAR sheet the same as a merchant ID?
No. The merchant ID (MID) is one field on it. A VAR sheet usually also lists a terminal ID and other processor settings, such as bank numbers and the merchant category code.
Is a VAR sheet confidential?
Treat it as private. It has no card numbers, but it identifies your merchant account. Share it only with the vendor setting up your terminal, POS or gateway, and send it privately.
Do I need a VAR sheet for Authorize.Net?
Usually not yourself. The processor details in Authorize.Net are set when the gateway is connected to your merchant account, and Authorize.Net's help page says changes beyond payment types go through its customer support. When START provides your merchant account, START sends the account details to Authorize.Net for you.
Connecting a client's software?
Tell us which software or gateway you're connecting, and we'll tell you what the merchant account needs to provide. START has been in payments for 20+ years and has set up more than 60,000 Authorize.Net accounts.
New to this topic? Start with our Merchant Services Reseller Program overview.
