Integrating Binance Pay for Multiple Merchants: Authorization, Isolation, and Deactivation

 / 
 / 
9

When integrating Binance Pay for multiple merchants, the easiest things to confuse are "who is receiving the money" and "who has permission to operate." In Binance Pay's merchant system, a Sub-Merchant is a virtual account and cannot log in. Its purpose is to let a Channel Partner manage order ownership for multiple merchants under the same main account. Payment authorization has two layers: when a Channel Partner uses its own API Key to create orders, it passes subMerchantId, and the money enters the corresponding merchant's settlement chain. If a technical service provider creates API calls on behalf of merchants, it must go through a separate authorization request process. The merchant must approve it on the Binance side before the provider can get a token to operate on their behalf.

Binance Exchange
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!

The word "deactivation" in the title does not have a corresponding "delete sub-merchant" or "deactivate sub-merchant" button in Binance's official documentation. The operations that can be confirmed are modifying sub-merchant information through the API or the merchant portal. If your goal is to stop a sub-merchant from continuing to receive payments, the practical approach is to stop creating new orders for that subMerchantId on the business side, and at the authorization level, have the merchant revoke the technical provider's authorization. The following explains the three areas: authorization, isolation, and deactivation.

Sub-merchant isolation depends on subMerchantId, not independent login

When creating a sub-merchant, the required information includes the sub-merchant name, store type (online/offline/both), MCC merchant category code, business registration number, registered country, and for online stores a site URL, while offline stores need an address. After successful creation, you get a subMerchantId, and this ID must be stored in your database.

The key action for isolation: every time you create an order on behalf of a sub-merchant, include the corresponding subMerchantId in the Create Order request. Order ownership is distinguished by this field. If you forget to pass it or pass the wrong one, the order will fall under the main merchant or the wrong sub-merchant, causing chaos in reconciliation and settlement later.

The sub-merchant account itself cannot be used to log in, and it has no independent password or backend entry. What "multi-merchant isolation" isolates is order ownership and report dimensions, not login permissions. In the Merchant Dashboard, you can view orders and export transaction reports by sub-merchant.

There are two ways to create a sub-merchant: call POST /binancepay/openapi/submerchant/add via API, or manually fill in the form in the Merchant Management Portal (MMP) under the [Partner Feature] tab by clicking [Add New Sub Merchant]. Brand Logo is optional. There are also two ways to modify information: the submerchant/modify API, or find the sub-merchant in the backend, click Edit, make changes, and confirm to save.

Technical providers need per-merchant authorization; one token cannot cover all merchants

If you are not a Channel Partner but a Technical Service Provider helping multiple merchants integrate Binance Pay, funds do not pass through you and settle directly to the merchant's Binance account. In this model, you need to configure webhooks in the merchant backend, then create an authorization request for every merchant.

The authorization process is: first call Query Scopes to check which permission scopes your technical provider account is allowed to request, such as CHECKOUT, PAYOUT, REFUND, and so on. Then call POST /binancepay/openapi/service/provider/create with the target merchant's merchantId and the required scopes. The response returns a redirectUrl. Guide the merchant to this URL, and the merchant approves or rejects it on the Binance side. After approval, your webhook receives a callback containing an authorizationToken. This token is unique for each merchant. Store it and use it for subsequent API calls on behalf of that merchant.

Here is a judgment that is easy to get wrong: you cannot use one merchant's token to operate on another merchant. In multi-merchant integration, token management must be isolated by merchant. The authorization request's bizStatus will be SUBMIT_AUTH_AGREE or a rejection status. You should handle it with branching logic based on the status instead of assuming approval by default.

"Deactivation" has no one-click switch; the real control points are on the business side and the authorization side

In Binance's public documentation, the only sub-merchant management operations available are creating and modifying information. There is no official API or button to delete or deactivate a sub-merchant. This means:

If you want to stop a sub-merchant from generating new orders, the practical approach is to stop creating new Checkout requests for that subMerchantId in your system. Orders that have already been created are not affected and will continue to settle as normal.

If you want to revoke a technical provider's authorization for a merchant, the merchant needs to do it on the Binance side. The specific revocation entry is not described in detail in the public documentation, so refer to the actual interface in the merchant backend. On the technical provider side, all you can do is stop using that token.

If the sub-merchant information was entered incorrectly, use the modification process rather than deactivating and recreating. After modification, the subMerchantId remains unchanged, and existing order ownership is not affected.

One editorial judgment: when integrating for multiple merchants, first determine whether you are a Channel Partner or a Technical Service Provider, because this decides which authorization path you take. A Channel Partner uses its own API Key plus subMerchantId to create orders directly. A Technical Service Provider needs to obtain an authorizationToken for each merchant. The two cannot be mixed. If you are only integrating payments for your own company and do not need to "collect payments on behalf of other merchants," you do not need to create sub-merchants. Just use Direct Merchant mode.

Binance Exchange
The world's largest cryptocurrency exchange by trading volume,leading in security and liquidity.
New user benefit: Enjoy 20% off trading fees upon registration!

References

  1. Binance·How to Amend Binance Pay Sub-Merchant Information?, accessed: 2026-10-22
  2. Binance·Create SubMerchant API, accessed: 2026-10-22
  3. Binance·Technical Service Provider, accessed: 2026-10-22