Gaming Supplier or Player Operator?

Does a supplier need the operator's payment brief?

It needs a brief describing its own activity. A software vendor invoicing licensed operators for development or licensing should explain those business-to-business sales. An operator taking player deposits and managing withdrawals has a different transaction flow. If the supplier also hosts games, operates a cashier or receives money on another business's behalf, those facts must be explicit.

Michigan's Gaming Control Board provides distinct operator, supplier and vendor information and application routes. In Great Britain, the Gambling Commission separately describes software and host activities. These are jurisdiction-specific examples, not a conclusion about a US supplier's license or a promise of payment acceptance in either market.

Sources: Michigan Gaming Control Board: Operator, Supplier and Vendor Information; Gambling Commission of Great Britain: Remote gambling software licence

What does the software actually do?

Describe the function in ordinary language: game content, operator reporting, customer-account tools or another service. Identify whether the business merely supplies software, hosts live facilities or participates in accepting and paying out player funds. A label such as B2B technology is not a substitute for that description.

For each revenue line, name the contracting business and what triggers its invoice. A fixed software license, an implementation fee and a fee tied to usage may require different forecasts. Explain the commercial basis without presenting operator turnover or player deposits as the supplier's own card-sales volume.

How can a hypothetical supplier separate the numbers?

Imagine a vendor charging three operators $5,000 each per month for reporting software. Its invoiced revenue in this simplified example is $15,000. The value of bets processed by the operators is not the vendor's payment volume merely because the software reports it. If the vendor also collects an implementation fee, show that separate customer payment and delivery obligation.

Now suppose the vendor proposes adding a shared payment portal that collects from players. That is not a cosmetic change to its invoice process. It creates a new role to assess with the relevant regulators, legal advisers and prospective payment partners. A supplier approval should never be presented as covering an unreviewed operator or funds-handling activity.

What licensing information is useful without overstating it?

List the legal entity, locations, activities, customer markets and current permissions the business believes apply. Distinguish issued licenses from applications and distinguish the supplier's permissions from its customers' permissions. If the classification is uncertain, say which question is with counsel or the regulator rather than filling in an assumed license category.

The Great Britain guidance is useful because it explicitly discusses software businesses that also host facilities. It should not be copied into a US checklist as though every state uses the same categories. Likewise, internet gaming, sports betting, fantasy contests and event contracts should not be combined under one generic permission.

What should the initial processing inquiry contain?

MerchantBridge can discuss the actual commercial opportunity and explore whether relevant partners may consider it. It does not issue licenses or determine regulatory status. Keep the inquiry about business payments; no player records, betting recommendations or consumer promotions are needed.

• Who contracts with the supplier and pays each invoice.
• Software functions and whether the supplier touches any player funds.
• Fixed, milestone, usage and other revenue components, with aggregate ranges.
• Applicable activities and markets, with issued and pending permissions distinguished.
• Delivery, cancellation and support responsibilities for the software contract.
• Requested payment methods and integration needs, identified as requests until confirmed.