⚙️VGS for Platforms (Multi-MID) - Merchant Service Onboarding

Enterprise Card Management for Platform Organizations

Multi-MID merchant service onboarding

Use this guide to plan CMP onboarding for a multi-MID platform model.

It covers merchant structure, service accounts, TRIDs, and tenant design.

Introduction

Start by deciding how each sub-merchant enrolls with the card networks.

That decision drives your account model, tenant model, and service setup.

Continue to VGS for Platforms (Multi-MID) - Implementation Guide after you finalize your merchant structure, TRID strategy, and tenant model.

---

Onboarding flow

1

Understand the CMP hierarchy

CMP supports platforms, PayFacs, merchant aggregators, and ISVs that manage credentials across multiple merchants through one integration.

Before you choose an onboarding model, align on the three core CMP entities:

• Organization — Your top-level company entity. It contains users, accounts, service accounts, and billing relationships.

• Account — Your merchant-level operating entity. It is where merchant enrollment happens and where CMP services are managed.

• Tenant — Your storage and configuration boundary. Token storage, service configuration, and scoped access are tenant-specific.

In a multi-merchant model, platforms often create one CMP account per merchant.

2

Choose a multi-merchant structure

Sub-merchants that register individually with the networks, or exceed volume thresholds, usually need their own CMP account, tenant, and service account.

Platforms can choose from several supported models.

Dedicated Account

Dedicated account per merchant

Each merchant gets its own CMP account, tenant, and service account.

Best for merchants above TRID volume thresholds.

Shared Account

Universal CMP Account

Hybrid Model

Model	Best for	Tenant	Service account	TRID
Dedicated account	Simple multi-MID structures on one platform	One tenant per merchant	One per merchant tenant	One per merchant
Shared account	Low-volume sub-merchants under TRID thresholds	One shared tenant	One shared account, or one per sub-merchant in the same tenant	One shared platform TRID
Universal CMP account	Platforms that need cross-merchant token portability	One main tenant plus sub-merchant CMP accounts	One per sub-merchant CMP account, plus one for the main tenant	Shared when merchants stay below thresholds
Hybrid model	ISVs and PayFacs with mixed merchant sizes	Shared tenant for low-volume merchants and dedicated tenants for high-volume merchants	Shared access for low-volume merchants and dedicated accounts for high-volume merchants	Shared for low-volume merchants and dedicated for high-volume merchants

Additional considerations

• MoR vs. PayFac — Merchant of Record platforms can register on behalf of sub-merchants and may use a shared tenant. PayFacs can process low-volume sub-merchants under the highest-level MID.

• Brands are not merchants — If multiple brands share credentials, each brand still needs its own merchant registration, tenant, and TRID.

• Shared PANs create multiple card objects — If the same PAN is enrolled across multiple merchants, CMP creates a different card_id for each merchant.

3

Register network services

To start network service registration, a VGS team member shares the CMP Enablement Form and password through 1Password.

The form submitter needs CMP Dashboard access.

Only verified users in your VGS organization receive access. Organization administrators can invite additional users as needed.

See Manage Users.

Select the CMP services you want to enable in the form.

If you do not have all network details yet, save the form as a draft and finish it later.

Merchants above network thresholds must enroll individually with their own network values.

Merchants below the thresholds usually do not need a separate form.

Enrollment rules by service

Network Tokens

• For Visa, Mastercard, and Discover, sub-merchants can enroll under a shared platform-level TRID.

• PayFacs can process low-volume sub-merchants under the highest-level MID.

Account Updater

• Sub-merchants below the thresholds can enroll with the platform at the TRID level.

• Visa uses a threshold of under $1M per year.

• Mastercard uses a threshold of under $10M per year.

• Merchants above those thresholds must enroll individually.

Network values required during onboarding

Scope	Network Tokens	Account Updater
Main organization	Visa — optional CAID + BIN Mastercard — optional Acquirer BIN/ID Amex — required SEID Discover — required MID	Not used
Sub-accounts	Visa — optional CAID + BIN Mastercard — optional Acquirer BIN/ID Amex — required SEID Discover — required MID	Visa — required CAID + BIN Mastercard — required Acquirer BIN/ID Amex — required SEID Discover — required MID

Only Direct Account merchants are eligible for Network Tokens and Account Updater.

OptBlue participants are not supported.

VGS verifies eligibility by submitting the merchant SEID to Amex and confirming Direct status and, when available, Top of Chain.

3D Secure

If each merchant processes transactions as the merchant of record, place each merchant in its own CMP account and tenant for 3DS.

Merchants can still live under one shared organization.

VGS enables 3DS at the CMP account level. A single shared merchant setup does not provide the merchant-level data segregation required for individual Merchants of Record.

4

Configure service accounts

How service accounts work in CMP

CMP requires a separate service account for each merchant that uses a dedicated tenant.

The dashboard does not support one service account across multiple sub-merchants.

Network Token scopes can be assigned to only one tenant per service account.

Service account checklist

• Generate a new production service account for CMP.

• Validate access to the Live API and confirm VGS Live IPs are allowlisted.

• Assign the required OAuth 2.0 scopes: cards, accounts, network_tokens, merchants.

• Confirm your backend can generate a production access token.

---

Token Requestor IDs

What is a TRID?

A Token Requestor ID, or TRID, is a network-assigned identifier used during Network Token enrollment.

Each network assigns TRIDs per merchant as part of its review process.

VGS does not issue shared or aggregate TRIDs.

Network Tokens vs. Account Updater

Service	Identifier used
Network Tokens	TRID for Visa and Mastercard, SEID for Amex, and MID for Discover
Account Updater	Acquiring BIN plus CAID for Visa, SEID for Amex, and MID for Discover

Account Updater does not use a TRID.

It uses separate network identifiers for enrollment.

Volume thresholds for shared TRIDs

Sub-merchants can enroll under a shared platform TRID when they remain within the applicable network thresholds.

Network	Threshold
Visa	Under $1M per year
Mastercard	Under $10M per year
Discover	No threshold
Amex	No threshold

Merchants above these thresholds should use a dedicated TRID, dedicated tenant, and dedicated CMP account.

Thresholds apply independently by network.

For example, a merchant processing $7M in Visa volume and $4M in Mastercard volume needs a dedicated TRID for Visa, but can remain on a shared TRID for Mastercard.

Recommended architecture for platforms

The hybrid model is a common fit for ISVs and platforms:

• Enroll lower-volume merchants under a shared platform TRID.

• Register higher-volume merchants individually with dedicated tenants, TRIDs, and CMP accounts.

This balances operational simplicity with network compliance.

TRID request process by network

Network	Method	Speed
Visa	API	A few days
Mastercard	API	A few days
Amex	Manual. Requires a Direct Merchant SEID.	Variable
Discover	Requires Discover MID.	Variable

---

Tenant architecture

Shared vs. dedicated tenant architecture

Your tenant architecture should match your TRID model.

Scenario	Recommended setup
Sub-merchants under volume thresholds	Shared account with a platform TRID
Sub-merchants above volume thresholds	Dedicated account, dedicated CMP tenant, and dedicated TRID
Migrating from a prior VGS setup	Create a new tenant when possible

Migrate from a prior VGS setup

If you are migrating card files from an earlier VGS CALM setup, create a new tenant instead of enabling CMP on an existing tenant when possible.

Reusing an older tenant can inherit a pre-existing merchant ID and create configuration conflicts.

Starting with a new tenant gives you a cleaner onboarding path.

You can migrate existing card files between tenants through an SFTP workflow.

See Migrating Cards on File to VGS for details.

How VGS uses the tenant

The tenant is the token store that maps aliases to the underlying PAN.

Because token resolution is tenant-specific, service accounts with Network Token scopes are also tenant-specific.

This means:

• Each merchant with Network Tokens enabled needs a service account scoped to its tenant.

• Multiple low-volume merchants can share a single tenant, but that model requires careful configuration management.

---

Go-live checks

Before you submit your production onboarding request, confirm the following:

• Correct tenant selected — Enable CMP on the correct tenant and environment.

• Routes promoted to production — Route configuration does not carry over between environments.

• Multiple merchants per organization — If you are onboarding more than one merchant in one organization, ensure allow_multiple_onboarding: true is set in the onboarding YAML.

• Webhook routing — Confirm Account Updater events route to the correct merchant context. One endpoint does not automatically handle all sub-merchants.