DEV Community: Wismook Teams

How to Connect Cryptomus to Perfect Panel: API Keys, Domain Verification and Fees

Wismook Teams — Sat, 17 Oct 2026 08:48:37 +0000

The Cryptomus connection in Perfect Panel comes down to a few fields. Getting those fields ready is the part that takes more attention: your account needs verification, your website needs merchant approval, and the API key must be the one for receiving payments.

I run ZOSMM Panel, and this guide follows the setup route used for a Perfect Panel website. It covers the existing Cryptomus payment integration, rather than building a separate checkout application from scratch.

Referral disclosure: the signup link below is my referral link. I may receive a commission if you register and use Cryptomus through it.

Start with the account, then create the merchant

Create a Cryptomus account and complete the identity verification requested in your account before proceeding with business payment setup. Follow the current checks shown in the dashboard; creating a login is not the same as being approved to accept payments.

Next, open Business → Merchants and choose Create merchant. Give the merchant a name you can recognize, then open its settings and enter your website URL and an accurate description of the business.

Cryptomus describes that process in its merchant setup instructions. Domain verification and project moderation are part of it. Submit the actual website and business details, then wait for the result rather than treating account registration as approval.

A merchant that is still under review is not ready just because the panel has somewhere to paste an API key.

Verify the domain on a Perfect Panel website

The domain verification step can be awkward when you use a hosted panel and do not have a conventional file manager. The route supplied for this setup uses Cryptomus's Using a meta tag on the site option.

Open your merchant settings in Cryptomus, find Confirm domain, and choose that method. Copy the verification tag exactly as supplied.

The Perfect Panel instructions for this route are:

Open Admin area → Settings → Integrations.
Open an integration that provides a Code snippet field.
Paste the Cryptomus verification tag into that field and save or activate it as required by the panel.
Return to Cryptomus and request domain verification.

There is a detail here worth checking before you move on: saving a snippet does not prove that it appears where the verifier expects it. The tag needs to be present on the public website in a location Cryptomus can recognize.

Use a suitable custom-code option if your panel exposes one. If you are following the support workaround that uses another integration's snippet field, confirm with Perfect Panel support that the selected integration accepts the tag in the required location. Do not replace existing working integration code just to make room for it.

Copy only the domain verification tag into public site code. Your Payment API Key belongs in the payment settings, never in this snippet.

Once the domain check succeeds, finish the merchant settings and submit any remaining moderation information. Domain ownership verification and merchant approval are separate checks.

Copy the Payment API Key and Merchant ID

After merchant approval, open the merchant settings and copy these two values:

Payment API Key
Merchant ID

Cryptomus separates payment keys from payout keys. For this connection, you want the key used to accept payments, not the one used to make withdrawals.

The current Getting API keys documentation shows the merchant creation, domain confirmation and moderation sequence. If an older instruction sends you to a documentation page that no longer opens, use that current page instead.

Keep both values associated with the same merchant. Copying an ID from one project and a key from another is an avoidable source of configuration problems.

Add the credentials in Perfect Panel

Open your panel's payment-method settings and add or edit the Cryptomus method. Enter the Merchant ID and Payment API Key in their matching fields.

Use the existing integration's setup instructions for any other fields it displays. This is configuration of a built-in connector; you do not need to publish your own API request script to complete these steps.

The credentials should stay in the admin payment configuration. If you share screenshots while asking for help, hide the API key first.

The remaining field that deserves a closer look is Subtract. Its name is less clear than its purpose.

Subtract controls who pays the processing commission

Subtract is the percentage of the payment commission passed to the customer. It is an integer from 0 to 100, with a documented default of 0.

It is not the commission rate itself.

With Subtract = 0, none of that processing commission is passed to the customer through this parameter. With Subtract = 100, the customer covers all of it. A value between those endpoints shares the commission.

Cryptomus gives a useful example in its invoice documentation: if your processing rate is 1% and the invoice is 100 USDT, setting Subtract = 100 makes the customer pay 101 USDT.

That is an example, not a statement that every merchant has a 1% rate. Check your actual rate and the amount shown on the generated invoice. Do not confuse the processing commission with a wallet's separate network transaction fee.

Also check whether you have configured an additional payment-method fee inside Perfect Panel. A separate panel surcharge and the Cryptomus commission allocation are different settings; make sure the checkout total reflects what you intended.

Check the full payment flow before relying on it

A saved payment method proves that the configuration was saved. It does not prove that a customer deposit will be credited correctly.

First check that the method appears on the customer-facing Add Funds page and that creating an invoice opens the expected Cryptomus payment page. Review the amount, selected currency and network, and any extra charge shown to the payer.

When you perform an authorized test payment, compare the invoice result with the deposit record and customer balance inside the panel. An invoice being created, a payment being detected, and a balance being credited are different events.

For a built-in integration, follow its documented notification setup. Do not invent a callback URL or paste an unrelated endpoint into merchant settings.

If the invoice is paid but the panel balance does not update, collect the invoice reference and the matching panel payment record for support. Avoid immediately adding a manual credit without checking whether an automatic update is still pending; otherwise the same deposit could be credited twice.

The final check is practical: the invoice shows the amount you intended, its payment result reaches the panel, and the customer receives the corresponding balance credit once.

SMM Panel API Integration: Connecting Is Easy, Keeping Orders in Sync Is Harder

Wismook Teams — Wed, 14 Oct 2026 12:42:09 +0000

At ZO Panel, we used to handle a situation that made this difference obvious. An order would be marked completed. The customer would dispute it, and after checking, we would find that it should have been canceled instead.
At ZO Panel, we used to handle a situation that made this difference obvious. An order would be marked completed. The customer would dispute it, and after checking, we would find that it should have been canceled instead.

The provider had to correct the order manually. Then we had to make the matching correction on our panel.

One customer order. Two separate updates.

Our current Perfect Panel connections handle that correction differently: when the order status changes on the connected side, the change can also reach our panel after the order has already been marked completed. We see this from both directions, whether we are buying from a provider or supplying services to a reseller.

That experience changed what I pay attention to when looking at an integration. A successful connection is a starting point. It does not tell you how the system will behave when an earlier status turns out to be wrong.

Disclosure: I run ZO Panel. The operational example above comes from our own workflow. The PHP example below is illustrative and has not been tested against a live account.

When both panels use Perfect Panel

In our workflow, a reseller using Perfect Panel can take the API key from their account profile on our panel and enter it in their own panel’s provider settings.

Perfect Panel’s provider connection guide explains why this is straightforward: providers using the same platform are already integrated, so the connection does not require writing a new API client.

There is still setup work. Connecting a provider and deciding which services to offer are separate decisions. Service selection, pricing, and synchronization settings deserve a check before customers start placing orders.

I would also avoid describing this as “everything syncs.” That phrase hides the details a reseller actually needs to understand.

Which service fields update? Which order changes reach the receiving panel? What happens to an order that was completed yesterday and corrected today?

Our experience with corrections after completion is useful, but it should not be treated as a promise about every installation. Perfect Panel’s public feature list also describes a manual option for requesting updated statuses of mistakenly completed orders. Verify the behavior of your own connection.

When the other system does not use Perfect Panel

For a custom application or another panel platform, start with the provider’s documented request format.

The ZO Panel API documentation specifies a POST endpoint at https://zosmm.com/api/v2, JSON responses, and actions for retrieving services, submitting orders, checking statuses, and checking balance.

An API key alone does not make an unrelated application compatible. The receiving software needs to support those requests and interpret the responses, either through an existing connector or code you write.

For a first connection check, retrieve the service list. There is no need to create a paid order just to check whether your application can communicate with the endpoint.

A small PHP request example

This example requires PHP 8 or later with cURL enabled. Store the key in the server’s environment as ZOSMM_API_KEY, rather than putting it in a public file or browser script.

<?php

function panelRequest(string $action, array $params = []): array
{
    $key = getenv('ZOSMM_API_KEY');

    if (!$key) {
        throw new RuntimeException('Missing API key.');
    }

    $ch = curl_init('https://zosmm.com/api/v2');

    curl_setopt_array($ch, [
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => http_build_query(
            array_merge($params, ['key' => $key, 'action' => $action])
        ),
        CURLOPT_HTTPHEADER => [
            'Content-Type: application/x-www-form-urlencoded',
        ],
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 10,
        CURLOPT_TIMEOUT => 30,
    ]);

    $body = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    $failed = $body === false;

    curl_close($ch);

    if ($failed) {
        throw new RuntimeException('Transport failure; outcome unknown.');
    }

    if ($httpCode < 200 || $httpCode >= 300) {
        throw new RuntimeException("Unexpected HTTP status: {$httpCode}");
    }

    $data = json_decode($body, true, 512, JSON_THROW_ON_ERROR);

    if (!is_array($data)) {
        throw new RuntimeException('Unexpected response structure.');
    }

    if (array_key_exists('error', $data)) {
        throw new RuntimeException('API returned an error; review securely.');
    }

    return $data;
}

$services = panelRequest('services');

printf("Received %d services.\n", count($services));

The timeouts are example client settings, not documented provider limits. This function handles a single request; it does not implement storage, scheduling, or order reconciliation.

Notice that it checks both the HTTP response and the decoded body. Those are different layers. Your application should not proceed simply because it received a response.

Keep your order ID and the provider’s order ID separate

When submitting an order, your application already has a local record. The provider returns its own order identifier.

Keep both.

Use the local identifier for your customer-facing order and the provider identifier for later status requests. Store the relationship before sending the order into any background processing workflow.

There is another detail worth handling before you automate submissions: a timeout leaves uncertainty.

Your application may stop waiting after the provider has accepted the request. Automatically submitting the same order again could create a duplicate. A timeout should therefore move the order into a review or reconciliation path, rather than trigger an unconditional retry.

The documentation reviewed for this example does not establish an idempotency mechanism. Do not assume repeated submissions are harmless.

A completed order may still need reconciliation

The correction we used to make manually exposes a weakness in a common design: stop checking an order forever as soon as it becomes completed.

That design is simple. It also means the application has no way to discover a later correction unless another process brings it back into view.

For a custom integration, distinguish the current order status from your policy for checking it again.

Active orders need routine updates. Disputed orders need a way to request a fresh status. Recently closed orders may need a separate reconciliation policy, depending on what the provider supports.

That does not mean polling every historical order indefinitely. It means deciding how corrections will reach your system instead of assuming they never happen.

Keep a history of corrections

Overwriting a status tells you what the order says now. Keeping a status history tells you what changed.

A useful record includes the previous status, the new status, the provider order ID, and when your application observed the change. Keep credentials out of that record.

Financial handling needs its own care. A status correction should not cause the same customer balance adjustment to run twice. Updating the displayed status and recording a refund are related operations, but they are not interchangeable.

Before relying on the connection, ask one concrete question: if the provider corrects an order after your system has closed it, how will that correction reach the customer’s order record?