POST /apiv2/screening

بلاک چین ایڈریس کے لیے AML اسکریننگ کا آرڈر دیں: ہر فراہم کنندہ (provider) اور آرڈر کی ہر حالت کے لیے ایک ہی رسپانس ساخت، اسٹرنگز کے طور پر اعشاری اعداد، اور ایک ہی ایرر فارمیٹ۔

اینڈ پوائنٹ URL

POST https://netts.io/apiv2/screening

درخواست کے ہیڈرز

ہیڈر	لازمی	تفصیل
Content-Type	ہاں	application/json
X-API-KEY	ہاں	Netts ڈیش بورڈ سے آپ کی API کی
X-Idempotency-Key	نہیں	محفوظ دوبارہ کوششوں (retries) کے لیے آپ کی اپنی کی (key)۔ دیکھیے Idempotency

درخواست باڈی

{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": true
}

پیرامیٹرز

پیرامیٹر	قسم	لازمی	تفصیل
address	string	ہاں	اسکرین کرنے کے لیے ایڈریس، 10–128 کریکٹرز
network	string	ہاں	نیٹ ورک ٹکر۔ ہر فراہم کنندہ جن ٹکرز کا احاطہ کرتا ہے وہ GET /apiv2/screening/providers کے ذریعے درج ہیں
provider	string	ہاں	elliptic یا bitok۔ کوئی ڈیفالٹ نہیں ہے
wait_for_result	boolean	نہیں	true زیادہ سے زیادہ 15 سیکنڈ تک نتیجے کا انتظار کرتا ہے۔ ڈیفالٹ false
language	string	نہیں	رپورٹ کی زبان۔ صرف en

نامعلوم فیلڈز مسترد کر دی جاتی ہیں۔ ایسا باڈی جس میں کوئی ایسی فیلڈ شامل ہو جو اوپر والے جدول میں نہیں ہے، وہ کوڈ 4001 کے ساتھ 400 واپس کرتا ہے۔

provider لازمی ہے اور اس کا کوئی ڈیفالٹ نہیں ہے۔ آپ ہمیشہ اس فراہم کنندہ کا انتخاب کرتے ہیں جس کے لیے آپ ادائیگی کرتے ہیں۔

اسکیما میں provider ایک فری فارم اسٹرنگ ہے، کوئی enumeration نہیں۔ آج دو اقدار قبول کی جاتی ہیں؛ تیسرا فراہم کنندہ کسی بھی ایسے شخص کے لیے بریکنگ تبدیلی نہیں ہونا چاہیے جو اسکیما کے مطابق رسپانسز کی توثیق کرتا ہے۔ موجودہ فہرست، وہ نیٹ ورکس جن کا ہر فراہم کنندہ احاطہ کرتا ہے اور وہ پیمانہ جس پر ہر ایک اسکور کرتا ہے، GET /apiv2/screening/providers سے حاصل ہوتے ہیں۔

مثالیں

cURL — نتیجے کا انتظار کریں

curl -X POST https://netts.io/apiv2/screening \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -d '{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": true
  }'

cURL — قبول کریں اور پول (poll) کریں

curl -X POST https://netts.io/apiv2/screening \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: your_api_key" \
  -d '{
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "bitok"
  }'

رسپانس 202 Accepted ہے جس میں ایک Location ہیڈر آرڈر کی طرف اشارہ کرتا ہے۔

Python

import requests
from decimal import Decimal

url = "https://netts.io/apiv2/screening"
headers = {
    "Content-Type": "application/json",
    "X-API-KEY": "your_api_key",
}
payload = {
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic",
    "wait_for_result": True,
}

response = requests.post(url, headers=headers, json=payload)

if response.status_code in (200, 202):
    body = response.json()
    print("Order:", body["order"]["client_order_id"])
    print("Status:", body["order"]["status"])
    if body["risk"]["score"] is not None:
        # Parse provider numbers as Decimal, never as float
        print("Score:", Decimal(body["risk"]["score"]), "of", body["risk"]["scale"]["max"])
    print("Level:", body["risk"]["level"], "-", body["risk"]["level_source"])
    print("Charged:", body["billing"]["charged_amount"], body["billing"]["charged_currency"])
else:
    problem = response.json()
    print(problem["code"], problem["title"], "-", problem["detail"])

جواب کے کوڈز

صورتحال	کوڈ	ہیڈرز
آرڈر بن گیا، اسکریننگ پس منظر میں چل رہی ہے	202 Accepted	Location: /apiv2/screening/{client_order_id}
نتیجہ رسپانس میں موجود ہے (wait_for_result)	200 OK	—
نتیجہ حالیہ جانچ سے دوبارہ استعمال کیا گیا، کوئی کٹوتی نہیں ہوئی	200 OK	—
ایڈریس کی کوئی بلاک چین سرگرمی نہیں ہے، کوئی کٹوتی نہیں ہوئی	200 OK	—
خرابی	دیکھیے Errors	Content-Type: application/problem+json

وہ رسپانسز جن میں اسکریننگ کا نتیجہ شامل ہوتا ہے، Cache-Control: private, no-store کے ساتھ بھیجے جاتے ہیں۔

جواب

{
  "schema_version": 2,
  "order": {
    "client_order_id": "A90D21F68C9AEA2",
    "status": "completed",
    "api_version": "v2",
    "cache_hit": false,
    "created_at": "2026-09-13T08:14:29.614988Z",
    "started_at": "2026-09-13T08:14:30.288251Z",
    "completed_at": "2026-09-13T08:14:34.993174Z"
  },
  "request": {
    "address": "YOUR_ADDRESS_HERE",
    "network": "trx",
    "provider": "elliptic"
  },
  "billing": {
    "charged": true,
    "price_usdt": "0.98",
    "base_amount": "2.882421",
    "markup_amount": "0",
    "charged_amount": "2.882421",
    "charged_currency": "TRX",
    "exchange_rate": "0.33999200",
    "payment_status": "pending"
  },
  "precheck": {
    "activity_checked": true,
    "activity_status": "active",
    "source": "tron-address-checker"
  },
  "check": {
    "provider": "elliptic",
    "provider_check_id": "b4903a5d-9f22-4075-b51b-beb40b419b97",
    "checked_at": "2026-09-13T08:14:32.144000Z",
    "status": "completed",
    "provider_status": "complete"
  },
  "risk": {
    "score": "0.9634087310611608",
    "scale": { "min": 0, "max": 10 },
    "level": "low",
    "level_source": "computed",
    "provider_level": null,
    "policy": "netts-risk-v1",
    "by_direction": {
      "source": "0.12332156899576921",
      "destination": "0.9634087310611608"
    }
  },
  "sanctions": {
    "self": false,
    "self_entities": null,
    "exposure": {
      "entity": "HTX (formerly Huobi) - Post-Sanctions - UK Sanctions List - 26 May 2026",
      "category": "Exchange",
      "share_fraction": "0.004409451392423414",
      "proximity": "indirect",
      "hops": 3,
      "direction": "source",
      "rule_name": "Sanctioned, TF & CSAM"
    },
    "items": []
  },
  "exposure": [
    {
      "category": "Exchange",
      "share_fraction": "0.1888065152442461",
      "direction": "source",
      "hops": 2,
      "is_screened_address": false,
      "entities": [
        { "name": "Binance", "category": "Exchange", "is_vasp": true,
          "is_primary": true, "is_after_sanction_date": null }
      ]
    }
  ],
  "rules": [
    { "name": "Sanctioned, TF & CSAM", "type": "exposure", "level": null,
      "score": "0.061426483114820525", "share_fraction": null, "category": null,
      "proximity": null, "direction": "source", "detected_at": null }
  ],
  "entities": [
    { "name": "Unknown", "category": "Unknown", "is_vasp": null,
      "is_primary": true, "is_after_sanction_date": false }
  ],
  "primary_entity": {
    "name": "Unknown", "category": "Unknown", "is_vasp": null,
    "is_primary": true, "is_after_sanction_date": false
  },
  "sanctioned_entities": [],
  "wallet": {
    "inflow_usd": "354663.6116669158",
    "outflow_usd": "80248.63081808022"
  },
  "provider_data": { }
}

فیلڈ کا مجموعہ کبھی تبدیل نہیں ہوتا

اوپر درج ہر بلاک ہر رسپانس میں موجود ہوتا ہے، چاہے فراہم کنندہ کوئی بھی ہو اور آرڈر کی حالت کچھ بھی ہو۔ جو چیز فراہم کنندہ فراہم نہیں کرتا وہ null ہوتی ہے؛ وہ فہرست جس میں کچھ نہیں ہے وہ [] ہوتی ہے، نہ کہ null؛ ایسا بلاک جس کا ڈیٹا ابھی تک نہیں ہے اسے چھوڑنے کے بجائے nulls سے پُر کیا جاتا ہے۔ ایک ہی پارسر اس جانچ کو بھی ہینڈل کرتا ہے جو ابھی قبول ہوئی ہے اور اسی جانچ کو بھی جب وہ مکمل ہو چکی ہو۔

آپ کے کوڈ کے لیے دو نتائج:

• ان فیلڈز کو نظر انداز کریں جنہیں آپ نہیں جانتے۔ ان بلاکس میں بغیر کسی نئے ورژن کے نئی فیلڈز شامل کی جاتی ہیں۔ کسی نامعلوم فیلڈ کو مسترد کرنا آپ کا بگ ہے، ہمارا نہیں؛
• provider_data معاہدے (contract) کا حصہ نہیں ہے۔ اس کی شکل فراہم کنندہ کے مطابق ہوتی ہے، اور فراہم کنندہ کے تبدیل ہونے پر یہ تبدیل ہو جاتی ہے۔ ہر وہ چیز جس کی معاہدہ ضمانت دیتا ہے وہ اوپر والے بلاکس میں موجود ہے۔

order

فیلڈ	قسم	تفصیل
client_order_id	string	آرڈر شناخت کنندہ، بعد میں نتیجہ پڑھنے کے لیے استعمال ہوتا ہے
status	string	pending، processing، completed، skipped، failed
api_version	string	وہ معاہدہ جس نے آرڈر بنایا
cache_hit	boolean	true جب حالیہ نتیجہ دوبارہ استعمال کیا گیا ہو اور کچھ چارج نہ کیا گیا ہو
created_at	string	RFC 3339، UTC، مائیکرو سیکنڈز
started_at	string | null	جب فراہم کنندہ کی کال شروع ہوئی۔ skipped کے لیے null
completed_at	string | null	جب نتیجہ موصول ہوا
error	string	صرف failed کے لیے: یہ کیوں ناکام ہوا
reason	string	صرف skipped کے لیے: address_inactive

تمام ٹائم اسٹیمپ UTC، RFC 3339 ہیں، جن میں Z لاحقہ اور مائیکرو سیکنڈ کی درستگی ہوتی ہے۔

billing

فیلڈ	قسم	تفصیل
charged	boolean	آیا رقم لی گئی تھی
price_usdt	string	USDT میں فراہم کنندہ کی فہرست قیمت
base_amount	string	چارج شدہ کرنسی میں آرڈر کی قیمت، بغیر ذیلی صارف مارک اپ کے
markup_amount	string	ذیلی صارف مارک اپ۔ براہ راست اکاؤنٹ کے لیے "0"
charged_amount	string	اصل میں بیلنس سے کیا لیا گیا تھا
charged_currency	string	TRX
exchange_rate	string | null	تبادلے کے لیے استعمال ہونے والی شرح
payment_status	string	paid، pending، failed، not_charged، postpaid

کامیاب جانچ کے بعد تھوڑے وقت کے لیے payment_status عارضی طور پر pending ہوتا ہے: چارج پہلے روکا جاتا ہے اور ایک گھنٹے کے اندر طے پاتا ہے۔ failed کا مطلب ہے کہ رقم واپس کر دی گئی تھی۔ not_charged کا مطلب ہے کہ کبھی کوئی چارج نہیں بنایا گیا تھا — دوبارہ استعمال شدہ نتیجہ یا چھوڑ دیا گیا ایڈریس۔ postpaid — دیکھیے Postpaid Accounts۔

precheck

ادا شدہ اسکریننگ سے پہلے ایڈریس کی بلاک چین سرگرمی کی جانچ کی جاتی ہے۔ بغیر کسی سرگرمی والے ایڈریس کو فراہم کنندہ کو نہیں بھیجا جاتا اور نہ ہی چارج کیا جاتا ہے۔

فیلڈ	قسم	تفصیل
activity_checked	boolean	آیا جانچ چلی تھی۔ ان نیٹ ورکس پر false جہاں یہ موجود نہیں ہے
activity_status	string	active، inactive، unknown
source	string | null	طریقہ کار کا نام

unknown ادا شدہ اسکریننگ کو نہیں روکتا: اگر سرگرمی کی سروس دستیاب نہ ہو تو ایڈریس کو ایکٹیو سمجھا جاتا ہے۔

check

فیلڈ	قسم	تفصیل
provider	string	وہ فراہم کنندہ جس نے جانچ انجام دی
provider_check_id	string | null	فراہم کنندہ کا اپنا شناخت کنندہ — ان کے ساتھ نتیجے پر تنازع کرتے وقت اس کا حوالہ دیں
checked_at	string | null	جب فراہم کنندہ نے نتیجہ تیار کیا
status	string	نیچے دیا گیا جدول دیکھیں
provider_status	string | null	فراہم کنندہ کے اپنے الفاظ، غیر ترمیم شدہ

order.status	check.status	مطلب
pending	pending	آرڈر قبول کر لیا گیا، ابھی شروع نہیں ہوا
processing	running	فراہم کنندہ اس پر کام کر رہا ہے
completed	completed	نتیجہ موصول ہو گیا
failed	failed	فراہم کنندہ کی کال سے پہلے یا اس کے دوران انکار کر دیا گیا
skipped	not_performed	ایڈریس کی کوئی سرگرمی نہیں ہے؛ فراہم کنندہ کو کبھی کال نہیں کیا گیا اور کچھ چارج نہیں کیا گیا

risk

فیلڈ	قسم	تفصیل
score	string | null	فراہم کنندہ کا اپنا اسکور، اعشاری اسٹرنگ کے طور پر
scale	object	اس فراہم کنندہ کے پیمانے کا min اور max
level	string	none، low، medium، high، severe
level_source	string	computed — ہم نے اسکور سے سطح اخذ کی؛ provider — فراہم کنندہ نے اسے بیان کیا
provider_level	string | null	فراہم کنندہ کا اپنا لفظ، جب وہ کوئی واپس کرتا ہے
policy	string	حد کی پالیسی کا نام، netts-risk-v1
by_direction	object	اسکور source اور destination میں تقسیم کیا گیا، جب فراہم کنندہ اسے تقسیم کرتا ہے

اسکور کو کبھی دوبارہ اسکیل نہیں کیا جاتا۔ Elliptic کا پیمانہ 0–10 ہے اور BitOK کا 0–1، اور ایک پیمانے پر 7 کا مطلب دوسرے پر کسی بھی معنی خیز لحاظ سے 0.7 نہیں ہے۔ پیمانہ رسپانس میں اس لیے آتا ہے تاکہ ایک فراہم کنندہ کے لیے لکھی گئی انٹیگریشن ایک کنفیگریشن تبدیلی کے بعد دوسرے کو غلط نہ سمجھے۔

لیول پوری API میں ایک ہی لغت ہے۔ جہاں فراہم کنندہ اپنی سطح خود بتاتا ہے ہم اسے آگے بڑھاتے ہیں اور level_source میں ایسا کہتے ہیں؛ جہاں وہ ایسا نہیں کرتا، ہم netts-risk-v1 کی حدود کے ساتھ اسکور سے لیول اخذ کرتے ہیں اور اس کے بجائے وہ بتاتے ہیں۔ ایک ہی جانچ کے لیے API رسپانس، ڈیش بورڈ اور PDF رپورٹ میں ایک ہی لفظ ظاہر ہوتا ہے۔

exposure[], rules[], entities[]

exposure[] فنڈز کو کاؤنٹر پارٹی کیٹیگری کے لحاظ سے توڑتا ہے۔ rules[] فراہم کنندہ کے ان اصولوں کی فہرست بناتا ہے جو لاگو ہوئے۔ entities[] ان اداروں کی فہرست بناتا ہے جن سے خود ایڈریس کا تعلق ہے؛ primary_entity ایک مقررہ اصول کے ذریعے ان میں سے ایک کا انتخاب کرتا ہے — وہ ادارہ جسے فراہم کنندہ نے پرائمری کے طور پر نشان زد کیا ہے، ورنہ پہلا، ورنہ null۔ sanctioned_entities[]، entities[] کے ان اداروں کو رکھتا ہے جنہیں پابندیوں کی تاریخ کے بعد ایکٹیو کے طور پر فلیگ کیا گیا ہے۔

شیئرز کسر (fractions) ہیں، کبھی فیصد نہیں

رسپانس میں ہر شیئر ایک واحد فیلڈ ہے، share_fraction، جو "0" اور "1" کے درمیان ایک اعشاری اسٹرنگ ہے۔

Elliptic reports 31.574732212596924 %  ->  "share_fraction": "0.31574732212596924"
BitOK reports    0.8488                ->  "share_fraction": "0.8488"

فراہم کنندگان یونٹس پر متفق نہیں ہیں: ایک ہی ایک تہائی exposure ایک سے 31.57 کے طور پر اور دوسرے سے 0.3157 کے طور پر موصول ہوتا ہے۔ فراہم کنندہ کو جانے بغیر دونوں کو لے جانے والی ایک واحد فیلڈ کو پڑھنا ناممکن ہوگا۔ فراہم کنندہ کا اپنا نمبر فراہم کنندہ کی اپنی اکائیوں میں provider_data میں رہتا ہے۔

اعداد اسٹرنگز ہیں

ہر وہ نمبر جو فراہم کنندہ کی طرف سے آتا ہے — اسکورز، شیئرز، USD والیومز، اور billing میں ہر رقم — ایک اعشاری اسٹرنگ ہے۔

"score": "0.9634087310611608"

JavaScript، Go یا بائنری فلوٹنگ پوائنٹ والی کسی بھی دوسری زبان میں اسے JSON نمبر کے طور پر پارس کرنا ایک تخمینہ دیتا ہے، اور جو قدر آپ پرنٹ کرتے ہیں وہ فراہم کنندہ کی جاری کردہ قدر سے مماثل نہیں رہتی۔ ان فیلڈز کو اعشاری قسم کے ساتھ پارس کریں: Python میں Decimal، Java میں BigDecimal، JavaScript میں decimal.Decimal یا ایک اسٹرنگ۔

وہ فیلڈز جو فراہم کنندہ کے بجائے ہماری ہیں — scale.min، scale.max، hops — سادہ JSON نمبرز ہیں۔

حالیہ نتیجہ کا دوبارہ استعمال

جب آپ 60 سیکنڈ کے اندر اسی ایڈریس، نیٹ ورک اور فراہم کنندہ کو دوبارہ اسکرین کرتے ہیں، تو سابقہ نتیجہ واپس کر دیا جاتا ہے اور کچھ بھی چارج نہیں کیا جاتا۔

ہر درخواست اب بھی اپنے client_order_id کے ساتھ اپنا آرڈر بناتی ہے؛ دوبارہ استعمال شدہ کو "cache_hit": true کے طور پر نشان زد کیا جاتا ہے اور اس کا billing بلاک "payment_status": "not_charged" کے ساتھ "charged": false رپورٹ کرتا ہے۔ جس آرڈر سے نتیجہ آیا اس کا شناخت کنندہ ظاہر نہیں کیا جاتا — ہو سکتا ہے کہ وہ کسی دوسرے اکاؤنٹ کا ہو۔

دوبارہ استعمال صرف ایک اکاؤنٹ کے اندر ہوتا ہے۔ کسی اور کے ذریعے اسکرین کیا گیا نتیجہ آپ کو کبھی واپس نہیں کیا جاتا۔

Idempotency

دوبارہ کوشش کو محفوظ بنانے کے لیے اپنی قدر کے ساتھ X-Idempotency-Key بھیجیں: اسی باڈی کے ساتھ وہی کی (key) دوسرا چیک آرڈر کرنے کے بجائے محفوظ شدہ رسپانس واپس کرتی ہے۔

صورتحال	کوڈ	رسپانس
اس کی (key) کے ساتھ پہلی درخواست اب بھی چل رہی ہے	409	4090
وہی کی، ایک مختلف درخواست باڈی	409	4093
وہی کی، وہی باڈی، پہلے ہی ختم ہو چکا ہے	محفوظ شدہ کوڈ	محفوظ شدہ رسپانس

اگر آپ ہیڈر نہیں بھیجتے ہیں، تو دو سیکنڈ کی ونڈو میں API کی، ایڈریس، فراہم کنندہ اور آپ کے IP ایڈریس سے آپ کے لیے ایک کی (key) تیار کی جاتی ہے۔ یہ ڈبل کلک اور گیٹ وے کے ری ٹرائی سے حفاظت کرتی ہے، ایک منٹ بعد دہرائے جانے سے نہیں: وہ ایک حقیقی نیا آرڈر ہوتا ہے اور چارج کیا جاتا ہے۔

خرابی کے جوابات

ایپلیکیشن کی طرف سے اٹھائی جانے والی ہر خرابی RFC 9457 کو Content-Type: application/problem+json کے ساتھ استعمال کرتی ہے:

{
  "type": "https://doc.netts.io/api/v2/errors/insufficient-funds",
  "title": "Insufficient funds",
  "status": 403,
  "detail": "Insufficient funds. Required: 2.888742 TRX, Available: 1.203000 TRX",
  "instance": "/apiv2/screening",
  "code": 1004,
  "required_trx": "2.888742",
  "available_trx": "1.203000"
}

type، title، status، detail اور instance معیاری فیلڈز ہیں۔ عددی code ایک توسیع ہے: اپنی خرابی کی ہینڈلنگ کو اس پر میچ کریں۔ اضافی فیلڈز خرابی پر منحصر ہیں اور جب آپ انہیں نہیں جانتے ہیں تو انہیں نظر انداز کر دیا جانا چاہیے۔

کوڈ	HTTP	مطلب
4000	400	باڈی درست JSON نہیں ہے
4001	400	ایک فیلڈ کی توثیق ناکام ہو گئی، یا ایک نامعلوم فیلڈ بھیجی گئی تھی
4002	403	یہ فراہم کنندہ آپ کے اکاؤنٹ کے لیے دستیاب نہیں ہے
4003	400	ناقص آرڈر شناخت کنندہ
4004	400	فراہم کنندہ درخواست کردہ نیٹ ورک کو سپورٹ نہیں کرتا ہے
4010	401	کوئی API کی نہیں ہے
4011	401	API کی یا IP ایڈریس قبول نہیں کیا گیا
4040	404	آرڈر نہیں ملا
4041	404	اکاؤنٹ نہیں ملا
4090	409	اس idempotency key کے ساتھ ایک درخواست اب بھی چل رہی ہے
4091	409	ڈپلیکیٹ درخواست
4093	409	یہ idempotency key ایک مختلف باڈی کے ساتھ استعمال ہوئی تھی
1004	403	بیلنس ناکافی ہے
5000	500	اندرونی خرابی
5001	500	چارج مکمل نہیں ہو سکا
5002	500	آرڈر نہیں بنایا گیا تھا
5030	503	فراہم کنندہ دستیاب نہیں ہے

ایسی خرابیاں جو اس فارمیٹ کو استعمال نہیں کرتی ہیں

کچھ ناکامیاں گیٹ وے پر ہوتی ہیں، اس سے پہلے کہ ایپلیکیشن تک پہنچا جائے، اور وہ گیٹ وے کی اپنی شکل برقرار رکھتی ہیں۔ کسی بھی ایسے رسپانس کو جس کا Content-Type، application/problem+json نہ ہو، ان میں سے ایک سمجھیں:

صورتحال	HTTP	باڈی
کوئی API کی نہیں، یا ایسی کی جو قبول نہیں کی گئی ہے	401	{"detail":{"code":-1,"msg":"Invalid or missing API key"}}
ریٹ کی حد سے تجاوز کر گیا	429	{"message":"API rate limit exceeded"}
نامعلوم راستہ، یا ایسا طریقہ جسے روٹ سروس نہیں دیتا	404 / 405	{"detail":"Method Not Allowed"}

شرح کی حدود

5 درخواستیں فی سیکنڈ اور 150 فی منٹ، جو تمام اسکریننگ راستوں کے ذریعے شیئر کی جاتی ہیں۔

پوسٹ پیڈ اکاؤنٹس

پوسٹ پیڈ بلنگ پر موجود اکاؤنٹس وہی اینڈ پوائنٹ، URL، ہیڈرز اور درخواست کی باڈی استعمال کرتے ہیں جو باقی سب کرتے ہیں۔ فرق یہ ہے کہ چیک کی ادائیگی کیسے کی جاتی ہے:

• آپ کے ڈپازٹ سے کچھ نہیں کاٹا جاتا ہے۔ امریکی ڈالرز میں ہر مکمل شدہ جانچ کی قیمت (مثال کے طور پر، Elliptic کے لیے $0.98) آپ کے معاہدے میں طے شدہ تصفیہ کرنسی میں آپ کے واجب الادا اکاؤنٹ بیلنس میں شامل کی جاتی ہے۔ آپ اپنے معاہدے کے مطابق انوائس کے ذریعے اس کی ادائیگی کرتے ہیں۔
• آپ کے اکاؤنٹ کی ایک کریڈٹ کی حد ہے۔ جب تک واجب الادا رقم حد کے اندر ہے، چیک صفر ڈپازٹ کے ساتھ بھی قبول کیے جاتے ہیں۔
• صرف مکمل شدہ چیکوں کا بل بھیجا جاتا ہے۔ ایسا چیک جو ناکام ہو گیا، بغیر کسی سرگرمی والا ایڈریس (skipped) اور دوبارہ استعمال شدہ حالیہ نتیجہ کی کوئی قیمت نہیں ہوتی۔

پوسٹ پیڈ بلنگ درخواست پر Netts کی طرف سے کسی اکاؤنٹ کے لیے فعال کی جاتی ہے۔

پوسٹ پیڈ چیک کا billing

"billing": {
    "charged": false,
    "price_usdt": "0.98",
    "base_amount": "2.960725",
    "markup_amount": "0",
    "charged_amount": "2.960725",
    "charged_currency": "TRX",
    "exchange_rate": "0.33100000",
    "payment_status": "postpaid"
}

فیلڈ	تفصیل
charged	false: ڈپازٹ سے کچھ نہیں لیا جاتا
price_usdt	امریکی ڈالر میں چیک کی قیمت۔ یہ وہ رقم ہے جو آپ کے واجب الادا بیلنس میں شامل کی گئی ہے
charged_amount	حوالہ کے لیے وہی قیمت TRX میں
payment_status	postpaid۔ ناکام یا چھوڑے گئے چیک کے لیے — not_charged

کریڈٹ کی حد ختم ہو گئی (402)

{
  "type": "https://doc.netts.io/api/v2/errors/credit-limit-reached",
  "title": "Postpaid credit limit reached",
  "status": 402,
  "detail": "Postpaid credit limit reached.",
  "instance": "/apiv2/screening",
  "code": 1004,
  "payment_mode": "postpaid",
  "reason": "limit_reached"
}

چیک کا آرڈر نہیں دیا جاتا اور نہ ہی کوئی بل بنایا جاتا ہے۔ آپ کی ادائیگی رجسٹر ہونے یا آپ کی حد بڑھنے کے بعد نئے چیک دوبارہ قبول کر لیے جاتے ہیں۔

پوسٹ پیڈ ایرر کوڈز

کوڈ	HTTP	تفصیل
1004	402	پوسٹ پیڈ کریڈٹ کی حد ختم ہو گئی
5032	503	قیمت عارضی طور پر دستیاب نہیں ہے
5034	503	بلنگ عارضی طور پر دستیاب نہیں ہے — چیک قبول نہیں کیا گیا تھا
5036	503	کریڈٹ چیک عارضی طور پر دستیاب نہیں ہے — بعد میں دوبارہ کوشش کریں

اوپر دیے گئے تمام رسپانسز کے لیے نہ تو کسی چیز کا آرڈر دیا جاتا ہے اور نہ ہی کوئی بل بنایا جاتا ہے۔

نوٹس

• قیمت کا تعین: ہر فراہم کنندہ کے لیے فی جانچ ایک مقررہ قیمت، دیکھیں GET /apiv2/screening/providers؛ رقم کٹوتی کے وقت کی شرح پر TRX بیلنس سے لی جاتی ہے۔
• پروسیسنگ کا وقت: زیادہ تر چیک چند سیکنڈ میں ختم ہو جاتے ہیں؛ طویل تاریخ والے ایڈریس میں تین منٹ تک لگ سکتے ہیں۔ غیر مطابقت پذیر (asynchronous) موڈ کا استعمال کریں اور GET /apiv2/screening/{client_order_id} کے ساتھ نتیجہ پڑھیں۔
• غیر فعال پتے skipped واپس کرتے ہیں اور ان سے چارج نہیں لیا جاتا ہے۔
• فراہم کنندہ کا اصل خام رسپانس کبھی واپس نہیں کیا جاتا ہے۔ provider_data ایک جائزہ شدہ پروجیکشن ہے؛ وہ فیلڈز جو اسکرین کیے گئے ایڈریس کے بجائے فراہم کنندہ کے ساتھ ہمارے اکاؤنٹ سے تعلق رکھتی ہیں، کسی کے لیے شائع نہیں کی جاتی ہیں۔

رپورٹس

اینڈ پوائنٹ صرف JSON واپس کرتا ہے اور کچھ نہیں۔ کوئی PDF اور کوئی Markdown نہیں ہے۔

ایک رپورٹ جس چیز سے بنتی ہے وہ سب پہلے سے ہی رسپانس میں موجود ہے: یونیفائیڈ بلاک اور provider_data۔ اسے اپنی طرف رینڈر کرنا آپ کو وہ دستاویز دیتا ہے جو آپ واقعی چاہتے ہیں — آپ کی برانڈنگ، آپ کی زبان، آپ کا لے آؤٹ — جو خاص طور پر اس صورت میں اہم ہے جب آپ چیکس کو دوبارہ فروخت کرتے ہیں، کیونکہ ہمارے نام پر مشتمل رپورٹ آپ کے اپنے صارف کو دینے کے لیے غلط دستاویز ہے۔

اگر آپ کو کسی تیسرے فریق کے لیے ثبوت کے طور پر ایک رپورٹ کی ضرورت ہے — ایک بینک، ایک ریگولیٹر، ایک کاؤنٹر پارٹی — تو نوٹ کریں کہ ایک غیر دستخط شدہ PDF ثبوت نہیں ہے چاہے اسے کوئی بھی تیار کرے: اسے ایک ٹیکسٹ ایڈیٹر میں ایک منٹ میں ایڈٹ کیا جا سکتا ہے۔ ایک قابل تصدیق نمونے کے لیے دستخط یا عوامی تصدیقی صفحے کی ضرورت ہوتی ہے، اور یہ ایک مختلف خصوصیت ہے۔ اگر آپ کا یہی معاملہ ہے تو ہمیں بتائیں کہ آپ کی کاؤنٹر پارٹی کو کیا ضرورت ہے۔

انہی چیکس کے لیے سترہ زبانوں میں Netts ڈیش بورڈ میں انسانی پڑھنے کے قابل PDF رپورٹس موجود ہیں۔

یہ بھی دیکھیں

• GET /apiv2/screening/{client_order_id} — ایک چیک پڑھیں
• GET /apiv2/screening/history — آپ کے چیک، کرسر کے ساتھ صفحہ بندی شدہ (cursor paginated)
• GET /apiv2/screening/providers — فراہم کنندگان، قیمتیں، نیٹ ورکس، پیمانے
• GET /apiv2/screening/price — ایک فراہم کنندہ کی قیمت
• Sanctions in an AML result — sanctions کیا کہتا ہے اور فراہم کنندہ کا فلیگ کیا کہتا ہے