{"id":110861,"date":"2026-03-26T12:26:31","date_gmt":"2026-03-26T16:26:31","guid":{"rendered":"https:\/\/animemangadaily.com\/sms-man-a-complete-disappointment-low-quality-sms-service-that-can-seize-your-entire-balance-without-warning"},"modified":"2026-03-26T12:26:31","modified_gmt":"2026-03-26T16:26:31","slug":"sms-man-a-complete-disappointment-low-quality-sms-service-that-can-seize-your-entire-balance-without-warning","status":"publish","type":"post","link":"https:\/\/animemangadaily.com\/sms-man-a-complete-disappointment-low-quality-sms-service-that-can-seize-your-entire-balance-without-warning","title":{"rendered":"SMS-MAN: A Complete Disappointment \u2014 Low-Quality SMS Service That Can Seize Your Entire Balance Without Warning"},"content":{"rendered":"
\n
⚠<\/div>\n

Warning to All API Resellers & Developers<\/h3>\n

If you are integrating SMS-MAN’s API into your platform, read this article carefully. Their undocumented penalty system can drain your entire account balance without any notification, and their support team will refuse to issue a refund. We learned this the hard way.<\/p>\n<\/div>\n

1. Background: Who We Are<\/h2>\n

We operate an SMS verification aggregator service<\/a> that integrates multiple SMS providers through their APIs. Our platform allows end users to purchase virtual phone numbers for SMS verification across hundreds of services and countries.<\/p>\n

As an aggregator, we rely on upstream providers like SMS-MAN to supply virtual numbers. We fetch pricing through their API, apply our markup, and present the options to our customers. We have no visibility or control<\/strong> over what end users actually do with the phone numbers once they are delivered.<\/p>\n

We integrated SMS-MAN as one of our primary providers in early 2026. For the first few weeks, everything seemed to work fine. Then, over a single weekend in March 2026, our entire $60+ balance vanished.<\/p>\n

This is the story of what happened, how it happened, and why we believe SMS-MAN’s business practices are deceptive and harmful to API resellers.<\/p>\n

2. The Pricing Deception: API Says $0.17, They Charge $6.34<\/h2>\n

SMS-MAN provides a get-prices<\/code> API endpoint that returns the cost for each service and country combination. Here is an actual API response for the “Ourtime” service in the United Kingdom:<\/p>\n

\/\/ API Request
\nGET http:\/\/api.sms-man.com\/control\/get-prices?token=***&country_id=100&application_id=2298<\/p>\n

\/\/ API Response
\n{
\n “2298”: {
\n “cost”: “13.38”, \/\/ 13.38 RUB = ~$0.17 USD
\n “count”: 1226,
\n “application_id”: “2298”,
\n “country_id”: “100”
\n }
\n}<\/p><\/div>\n

Based on this response, we set our selling price at $1.02<\/strong> per number \u2014 a healthy markup over the $0.17 API-reported cost. Reasonable, right?<\/p>\n

Here’s what we discovered on SMS-MAN’s own dashboard after those numbers were used:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Phone Number<\/th>\nAPI Reported Cost<\/th>\nActual Charge<\/th>\nDifference<\/th>\n<\/tr>\n<\/thead>\n
+44789XXXXX36<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44791XXXXX81<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44773XXXXX86<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44789XXXXX38<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44773XXXXX59<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44773XXXXX80<\/td>\n$0.17<\/td>\n$6.40<\/td>\n38x higher<\/td>\n<\/tr>\n
+44736XXXXX05<\/td>\n$0.17<\/td>\n$6.40<\/td>\n38x higher<\/td>\n<\/tr>\n
+44773XXXXX60<\/td>\n$0.17<\/td>\n$6.40<\/td>\n38x higher<\/td>\n<\/tr>\n
+44746XXXXX48<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n
+44749XXXXX52<\/td>\n$0.17<\/td>\n$6.34<\/td>\n37x higher<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

The total actual cost for 10 orders: ~$63<\/strong>
\nThe total API-reported cost for 10 orders: $1.70
\nThe total we charged our users: $10.20
\nOur net loss: ~$53 \u2014 just from these 10 orders.<\/strong><\/p>\n<\/blockquote>\n

We also verified the charges through SMS-MAN’s own get-balance<\/code> API. At the time of each purchase, only 13.38 RUB ($0.17) was deducted from our balance. But between purchases, we observed massive unexplained balance drops:<\/p>\n

\/\/ Balance tracking via get-balance API<\/p>\n

18:17 \u2014 Buy number \u2192 Balance: $57.62 \u2192 $57.46 (only $0.16 deducted)
\n18:32 \u2014 Buy number \u2192 Balance: $51.29 \u2192 $51.12 (WHERE DID $6.17 GO?)
\n19:02 \u2014 Buy number \u2192 Balance: $51.29 \u2192 $51.12 (only $0.16 deducted)
\n19:13 \u2014 Buy number \u2192 Balance: $44.96 \u2192 $44.79 (WHERE DID $6.33 GO?)<\/p>\n

\/\/ Pattern: $0.17 deducted at purchase, ~$6.17 silently deducted later
\n\/\/ No API notification. No email. No webhook. Nothing.<\/p><\/div>\n

3. The Silent Fine System: $60 Gone Without a Single Notification<\/h2>\n

After our balance hit $0.00 and we started investigating, we received this email from SMS-MAN support:<\/p>\n

\n

“Hello. You have been fined for violating the site’s terms of use. You used Ourtime numbers to register on Meetic.”<\/em><\/p>\n<\/blockquote>\n

Let us break down what happened:<\/p>\n

What SMS-MAN Claims<\/h3>\n

An end user on our platform selected “Ourtime” as the service but actually used the phone number to verify an account on “Meetic” \u2014 a different dating platform. SMS-MAN considers this “cross-service abuse” and applies a penalty fee equal to the price of the more expensive service.<\/p>\n

The Problem<\/h3>\n
    \n
  • We are an API reseller.<\/strong> We call their API with the service code, they return a phone number, we display it to the user. That’s it. We have zero visibility into which website our end user actually enters the number on.<\/li>\n
  • Only SMS-MAN can detect this.<\/strong> They see the actual SMS content (e.g., “Your Meetic verification code is: 277590”). They know it came from Meetic, not Ourtime. We never see this information.<\/li>\n
  • The fines were applied silently.<\/strong> No email, no API callback, no webhook, no notification of any kind. Our balance was drained over a weekend and we only found out when it hit $0.00.<\/li>\n
  • Their API provides no mechanism to prevent this.<\/strong> No real-time abuse detection callback. No way to verify which service the SMS actually came from. No fine notification endpoint.<\/li>\n<\/ul>\n

    Timeline of Events<\/h3>\n
      \n
    • March 16, 2026 \u2014 18:00:<\/strong> Account balance: $57.62. Everything looks normal. End user begins ordering Ourtime numbers.<\/li>\n
    • March 16, 2026 \u2014 18:17 to 23:02:<\/strong> Multiple Ourtime UK orders placed. API deducts $0.17 per number. But between orders, balance drops by $6+ each time. Silent fines being applied.<\/li>\n
    • March 17, 2026 \u2014 13:52:<\/strong> Last successful order. Balance drops to $0.45. All subsequent orders fail with “balance is 0” error.<\/li>\n
    • March 17, 2026 \u2014 14:00+:<\/strong> We discover the balance is $0.00. Begin investigation. No email from SMS-MAN. No notification anywhere.<\/li>\n
    • March 17, 2026 \u2014 Evening:<\/strong> We contact SMS-MAN support requesting an explanation and refund.<\/li>\n
    • March 18, 2026:<\/strong> SMS-MAN responds: “You have been fined.” Account status: closed.<\/li>\n<\/ul>\n

      4. Technical Evidence<\/h2>\n

      We maintain comprehensive server-side logging of all API interactions. Here is the evidence chain:<\/p>\n

      4.1 Balance Tracking Logs<\/h3>\n

      Our system calls get-balance<\/code> before and after every purchase. The logs clearly show:<\/p>\n

        \n
      • At purchase time: only 13.38 RUB deducted (matching the get-prices<\/code> response)<\/li>\n
      • Between purchases: balance drops by 500+ RUB with no corresponding API call from our side<\/li>\n
      • The “phantom” deductions match exactly with the dashboard-reported fines ($6.34-$6.40 per completed order)<\/li>\n<\/ul>\n

        4.2 Provider Transaction Logs<\/h3>\n

        Every SMS-MAN API interaction is logged in our provider_transactions<\/code> table with timestamps, balance snapshots, and amounts. All 10 completed UK Ourtime orders show:<\/p>\n

        \/\/ Example: provider_transactions log entry
        \ntype: buy
        \nservice: ourtime, country: GB
        \nbalance_before: 57.6252 (USD, converted from RUB)
        \nbalance_after: 57.4601
        \namount_deducted: 0.1651
        \ncost_rub: 13.38
        \nexchange_rate: 81.05<\/p>\n

        \/\/ Only $0.16 deducted at purchase time.
        \n\/\/ The remaining ~$6.18 charged silently, later, with no API trace.<\/p><\/div>\n

        4.3 SMS-MAN Dashboard Confirmation<\/h3>\n

        SMS-MAN’s own dashboard shows the true charges. For each completed UK Ourtime number where the SMS was received, the dashboard displays $6.34<\/strong> or $6.40<\/strong> \u2014 not the $0.17 reported by the API.<\/p>\n

        For numbers where no SMS was received (cancelled\/expired), the dashboard shows $0.17 \u2014 confirming that the API price is only a “reservation fee” and the real charge is applied after SMS delivery.<\/p>\n

        \n

        Key finding:<\/strong> SMS-MAN’s get-prices<\/code> API returns a “reservation fee” ($0.17), not the actual cost. The real charge ($6.34) is only visible on the dashboard after SMS delivery. There is no API endpoint that returns the actual\/final cost. This makes it impossible for API integrators to set accurate pricing.<\/p>\n<\/blockquote>\n

        5. Their Support Response: Blame the Reseller<\/h2>\n

        We sent three detailed emails to SMS-MAN support with full technical evidence. Here is a summary of the exchange:<\/p>\n

        Our First Email<\/h3>\n

        We explained the pricing discrepancy, provided API response logs, balance tracking data, and requested a refund of ~$57.<\/p>\n

        Their Response #1<\/h3>\n
        \n

        “The person who registered the account is responsible for all actions taken on the website, not the end user. Fines are issued automatically by the system and cannot be canceled. This applies to all users of the website without exception.”<\/em><\/p>\n<\/blockquote>\n

        Their Response #2<\/h3>\n
        \n

        “Your client selected a cheaper service ‘Ourtime’ but used the numbers for a more expensive service ‘Meetic’. This could not have been accidental. This does not appear to be a coincidence, but rather intentional system abuse.”<\/em><\/p>\n<\/blockquote>\n

        They accused us of “intentional system abuse” \u2014 a serious allegation against a legitimate business that simply integrated their API.<\/p>\n

        Their Response #3<\/h3>\n
        \n

        “As a direct provider using only our own numbers, we incur losses with every such abuse attempt on your side, and this is not the first time. Previously, it happened with Turkey and Netflix.”<\/em><\/p>\n<\/blockquote>\n

        They admitted this has happened before \u2014 yet they implemented zero API-level protections<\/strong> to prevent it. No webhook, no callback, no real-time notification. Nothing.<\/p>\n

        Refund Status: Denied<\/h3>\n

        Despite three emails with comprehensive technical evidence, SMS-MAN refused to issue any refund<\/strong>. They closed our account and kept our money.<\/p>\n

        6. Why This Is Fundamentally Unfair<\/h2>\n

        Let’s examine the technical chain of a typical transaction:<\/p>\n

        \/\/ The complete transaction flow:<\/p>\n

        Step 1: End user selects “Ourtime” on our platform
        \nStep 2: We call SMS-MAN API: get-number?application_id=2298&country_id=100
        \nStep 3: SMS-MAN returns a phone number
        \nStep 4: We display the number to the end user
        \nStep 5: End user enters the number on Meetic (NOT visible to us)
        \nStep 6: SMS-MAN receives SMS: “Your Meetic code is: XXXXXX”
        \nStep 7: SMS-MAN detects cross-service usage and applies fine<\/p>\n

        \/\/ Steps 1-4: All we can do. Steps 5-7: Only SMS-MAN can see.<\/p><\/div>\n

        What SMS-MAN Could Do (But Doesn’t)<\/h3>\n