USDT পাওয়ার আগে ক্লায়েন্ট চেকলিস্ট

সর্বশেষ হালনাগাদ: 2026-08-11 উৎস যাচাই: 2026-08-10T18:21:00+08:00

ক্লায়েন্ট “USDT পাঠিয়ে দিচ্ছি” বললেই ঠিকানা পাঠানো উচিত নয়। প্রথমে অন্তত ছয়টি বিষয় লিখিতভাবে মিলতে হবে: কোন অ্যাসেট, কোন নেটওয়ার্ক, কত অঙ্ক, ফি কে দেবে, কোন ইনভয়েসের পেমেন্ট এবং পাঠানোর পর কোন প্রমাণ পাওয়া যাবে। বাংলাদেশে বসে পেমেন্ট নিলে আরও একটি আগের প্রশ্ন আছে—প্রস্তাবিত মাধ্যমটি বর্তমান বৈদেশিক মুদ্রা নির্দেশনার সঙ্গে সামঞ্জস্যপূর্ণ কি না। এই চেকলিস্ট প্রযুক্তিগত ভুল কমায়; কোনো পেমেন্ট মাধ্যমকে আইনসম্মত ঘোষণা করে না।

পাঠানোর আগে সবচেয়ে ছোট উত্তর কী?

ক্লায়েন্ট ও প্রাপক একই লিখিত বাক্যে USDT, সুনির্দিষ্ট নেটওয়ার্ক, মোট অঙ্ক, ফি বহনকারী, ইনভয়েস নম্বর এবং পেমেন্টের অবস্থা নিশ্চিত না করা পর্যন্ত পাঠানো থামিয়ে রাখুন। “USDT”, “TRC20”, “ঠিকানা” বা “হ্যাশ”—একটি শব্দ একা যথেষ্ট নয়। নিশ্চিতকরণে সব ক্ষেত্র পাশাপাশি থাকলে পুরোনো বার্তা, কপি-পেস্ট বা ভিন্ন নেটওয়ার্কের তথ্য মিশে যাওয়ার ঝুঁকি কমে।

এখানে কোনো বাস্তব ওয়ালেট ঠিকানা, ব্যক্তিগত কী, সিড ফ্রেজ বা লগইন তথ্য চাওয়া হচ্ছে না। ঠিকানা কেবল প্রাপকের বর্তমান গ্রহণকারী সেবা থেকে, নিরাপদ ও আলাদা মাধ্যমে নিতে হবে। এই পাতার শেষে যে কার্ড আছে সেটি কথোপকথনের সিদ্ধান্ত নথিভুক্ত করে; সেটি ওয়ালেট ফরম নয় এবং কোনো অর্থ পাঠায় না।

প্রথম ধাপ কি নিয়ন্ত্রক যাচাই?

বাংলাদেশি ফ্রিল্যান্সারের ক্ষেত্রে হ্যাঁ। বাংলাদেশ ব্যাংকের FE সার্কুলার No. 24 বাংলাদেশে, বাংলাদেশ থেকে বা বাংলাদেশের উদ্দেশে ভার্চুয়াল অ্যাসেট পাওয়ার জন্য নির্দিষ্ট লেনদেন ও সংশ্লিষ্ট সহায়তার ওপর নিষেধমূলক অবস্থান জানায়। তাই “ঠিকানা ঠিক আছে” সিদ্ধান্তটি “এই পেমেন্ট ব্যবস্থা গ্রহণযোগ্য” সিদ্ধান্তের বিকল্প নয়।

ক্লায়েন্ট USDT প্রস্তাব করলে কার্যকর নির্দেশনা দেওয়ার আগে আপনার Authorized Dealer বা AD ব্যাংকের কাছে কাজ, ইনভয়েস, ক্লায়েন্টের দেশ, মুদ্রা ও প্রস্তাবিত মাধ্যমের তথ্য দিন। অনুমোদিত ফিয়াট সেবা-রপ্তানি পথ কী এবং কোন আগত রেমিট্যান্স নথি লাগবে—লিখিতভাবে জিজ্ঞাসা করুন। উত্তর অস্পষ্ট থাকলে প্রযুক্তিগত চেকলিস্টে এগিয়ে যাবেন না।

“USDT” লিখলেই কি অ্যাসেট নিশ্চিত হয়?

না। Tether-এর supported protocols পাতা Ethereum ও TRON-সহ বিভিন্ন প্রোটোকলের জন্য আলাদা তথ্য ও কনট্রাক্ট রেফারেন্স প্রকাশ করে। একই টোকেনের নাম একাধিক নেটওয়ার্কে দেখা যাওয়ায় ক্লায়েন্টকে শুধু ticker নয়, প্রেরণকারী সেবায় দেখা পূর্ণ asset label এবং network label লিখতে বলুন।

একটি ভালো উত্তর হবে: “Asset: USDT; Network shown by sender: TRON (TRC20)”—শুধু “Tether” নয়। প্রাপকের সেবায় একই নাম বর্তমানে সমর্থিত কি না প্রাপক নিজে দেখবেন। কোনো পুরোনো স্ক্রিনশট, বন্ধুর অভিজ্ঞতা বা সার্চ ফলের সংক্ষিপ্ত অংশকে বর্তমান সমর্থনের প্রমাণ ধরবেন না।

নেটওয়ার্কের নাম কীভাবে নিশ্চিত করবেন?

প্রেরক ও প্রাপক দুজন নিজ নিজ সেবায় একই সময়ে নেটওয়ার্কের পূর্ণ নাম দেখবেন। TRC20, ERC20 এবং BEP20 দেখতে ছোট লেবেল হলেও তারা একই পরিবহন পথ নয়। প্রাপকের পাশে ERC20 এবং প্রেরকের পাশে TRC20 থাকলে ঠিকানার অক্ষর দেখে অনুমান করবেন না; এটি স্পষ্ট mismatch, তাই পেমেন্ট বন্ধ থাকবে।

BNB Chain-এর বর্তমান wallet FAQ টোকেন না দেখা গেলে transaction status, recipient address, token এবং exact network পরীক্ষা করতে বলে। একই পাতা বোঝায় BNB Smart Chain-এর টোকেন Ethereum Mainnet বা opBNB-তে নিজে থেকে দেখা যায় না। ফলে “দুই ঠিকানাই 0x দিয়ে শুরু” কোনো network agreement নয়।

ঠিকানা কোথা থেকে নেওয়া উচিত?

প্রাপক যে সেবা বা ওয়ালেটে অর্থ পেতে চান, সেই বর্তমান deposit বা receive flow থেকে ঠিকানা নেবেন। পুরোনো ইনভয়েস, নোট অ্যাপ, চ্যাটের অনেক আগের বার্তা বা অন্য অ্যাসেটের ঠিকানা থেকে কপি করবেন না। ঠিকানা নেওয়ার সময় asset ও network label একই পর্দায় দেখা গেলে সেই প্রসঙ্গ নথিতে রাখা সহজ হয়।

Ethereum accounts documentation ব্যবহারকারী-নিয়ন্ত্রিত account এবং contract account-এর পার্থক্য ব্যাখ্যা করে; উভয় ধরনের account টোকেন ধারণ করতে পারে। তাই শুধু address format দেখে প্রাপক কে, ঠিকানাটি custodial কি না, বা জমা স্বয়ংক্রিয়ভাবে credit হবে কি না জানা যায় না। প্রাপক সেবার বর্তমান নির্দেশনাই সিদ্ধান্তের উৎস।

কপি-পেস্ট করার পরে কী মিলাবেন?

ঠিকানার শুরু ও শেষের কয়েকটি অক্ষর উৎসের সঙ্গে মিলিয়ে দেখা transcription ভুল ধরতে সাহায্য করে। কিন্তু এটি পূর্ণ নিরাপত্তা পরীক্ষা নয়। পুরো ঠিকানাটি একই উৎস থেকে এসেছে কি না, মাঝখানে অক্ষর বাদ গেছে কি না এবং asset/network context বদলায়নি কি না দেখুন। QR ব্যবহার করলেও স্ক্যানের ফল পর্দায় পড়ে মিলিয়ে নিন।

ক্লায়েন্টকে ঠিকানা পুনরায় টাইপ করতে বলবেন না; টাইপ করলে নতুন ভুল হয়। প্রাপকও কোনো গোপন তথ্য দিয়ে ownership “প্রমাণ” করবেন না। পাবলিক receiving address শেয়ার করা এবং private key বা seed phrase শেয়ার করা সম্পূর্ণ আলাদা বিষয়; পরের দুটি কখনো চাওয়া বা পাঠানো যাবে না।

অঙ্ক ও ইনভয়েস কীভাবে বাঁধবেন?

পেমেন্ট বার্তায় invoice number, invoice currency, agreed gross amount এবং USDT amount আলাদা লিখুন। “500” একা অসম্পূর্ণ—এটি USD, USDT নাকি BDT বোঝা যায় না। কিস্তি হলে “installment 1 of 3” এবং ওই কিস্তির নির্দিষ্ট অঙ্ক লিখুন। একই ক্লায়েন্টের একাধিক invoice থাকলে প্রতিটির জন্য আলাদা confirmation রাখুন।

কোট তৈরির সময় ব্যবহৃত rate, platform percentage, fixed fee, network fee এবং spread অনুমান থাকলে তা “estimate” হিসেবে চিহ্নিত করুন। ক্লায়েন্ট কত পাঠাবে এবং আপনি কত credit আশা করছেন—দুটি এক না হলে পার্থক্যের কারণ আগে লিখুন। অমিলকে পরে “সম্ভবত fee” বলে পূরণ করা দুর্বল প্রমাণ।

ফি কে বহন করবে তা কেন আগে লিখবেন?

“Client pays all fees” কথাটি যথেষ্ট নির্দিষ্ট নয়। platform fee কি gross amount থেকে কাটবে, sender আলাদা network fee দেবে, নাকি recipient service credit থেকে কিছু কাটবে—প্রতিটি প্রশ্ন আলাদা। ERC20 transfer-এর ক্ষেত্রে Ethereum gas documentation দেখায় state-changing transaction-এর gas fee ETH-তে পরিশোধিত হয় এবং demand অনুযায়ী fee component বদলাতে পারে। তাই quote-এর পুরোনো fee-কে স্থির সত্য ধরবেন না।

ফি সংক্রান্ত লিখিত সম্মতিতে অন্তত চারটি ঘর রাখুন: percentage fee, fixed deduction, network fee bearer এবং shortfall হলে কে সমন্বয় করবে। প্রকৃত fee জানা না থাকলে শূন্য লিখবেন না; “unknown until payment screen” লিখুন। শূন্য একটি বাস্তব অঙ্ক, অজানা তথ্যের প্রতীক নয়।

ছোট পরীক্ষামূলক পেমেন্ট কি বাধ্যতামূলক?

না; test amount একটি risk-control option, নিশ্চয়তা নয়। ছোট পেমেন্টেও ভুল নেটওয়ার্কে ক্ষতি হতে পারে, platform minimum বা fee কারণে অকার্যকর হতে পারে, এবং প্রথম credit হওয়া পরের বড় পেমেন্ট নিশ্চিত করে না। test দরকার কি না, তার অঙ্ক ও অতিরিক্ত fixed fee আগে বিবেচনা করুন। বাংলাদেশি নিয়ন্ত্রক প্রশ্ন অমীমাংসিত থাকলে test payment-ও করা উচিত নয়।

যদি প্রযোজ্য প্রতিষ্ঠান test অনুমোদন করে এবং দুই পক্ষ তা বেছে নেয়, আগে লিখুন test-এর পরে কোন প্রমাণ দেখলে বাকি অঙ্ক পাঠানো হবে। শুধু sender-এর “success” স্ক্রিন নয়; recipient service-এ সঠিক asset/network-এ usable credit দেখা এবং transaction reference মেলানো দরকার।

পাঠানোর পরে ক্লায়েন্টের কাছ থেকে কী নেবেন?

Ethereum transaction documentation sender, recipient, value বা input, gas fields এবং transaction hash-এর জীবনচক্র ব্যাখ্যা করে। ক্লায়েন্টের কাছ থেকে transaction hash, sender service reference, পাঠানোর সময় ও অঙ্ক নিন। কিন্তু hash পাওয়া মানেই final credit নয়; block inclusion, status এবং recipient service credit আলাদা অবস্থা।

TRC20-এর ক্ষেত্রে TRON transaction lifecycle create, sign, broadcast, validate, block inclusion এবং solidification আলাদা ধাপ হিসেবে দেখায়। তাই “broadcast হয়েছে” এবং “fully confirmed” একই বাক্য নয়। আপনার রেকর্ডে sender status, public network status এবং recipient credit status আলাদা রাখুন।

explorer-এ কী মিলবে, আর কী মিলবে না?

প্রাসঙ্গিক public record-এ hash, network, token/contract, recipient, amount এবং status মিলতে পারে। এটি ক্লায়েন্টের আইনি পরিচয়, invoice purpose, কাজ হস্তান্তর বা বৈদেশিক মুদ্রা অনুমোদন প্রমাণ করে না। explorer-এ success দেখালেও custodial service memo, minimum, unsupported token বা internal review কারণে usable balance না-ও দেখা যেতে পারে।

তাই evidence chain হবে: client confirmation → invoice → transaction reference → public network record → recipient statement। কোনো ধাপ অনুপস্থিত হলে “missing” লিখুন। স্ক্রিনশট দিয়ে অমিল ঢাকার চেষ্টা করবেন না; মূল link বা platform statement থাকলে সেটিও সংরক্ষণ করুন।

mismatch দেখলে কী করবেন?

অ্যাসেট, network, contract, recipient বা amount-এর যেকোনো একটিতে অমিল হলে নতুন ঠিকানা পাঠিয়ে কথোপকথন চালিয়ে যাবেন না। স্পষ্টভাবে লিখুন “Do not send / পাঠাবেন না”, পুরোনো নির্দেশনা বাতিল চিহ্নিত করুন এবং নতুন করে সব ক্ষেত্র পূরণ করুন। ক্লায়েন্ট ইতিমধ্যে পাঠিয়ে থাকলে আরেকটি transfer দিয়ে “ঠিক” করার চেষ্টা করবেন না।

প্রেরণকারী ও গ্রহণকারী সেবার official support channel-এ সত্য তথ্য দিন। private recovery service, গোপন exchange বা credential চাওয়া ব্যক্তির কাছে যাবেন না। ভুল network recovery সম্ভব কি না সেবাভেদে বদলে যায়; এই checklist recovery guarantee দেয় না।

কোন নথি মাসিক আয় ফাইলে যাবে?

নিরাপদ রেকর্ডে confirmation card, invoice, client alias, payment time, asset, network, gross amount, received amount, hash, fee evidence এবং exception note থাকবে। public address বা client legal name কেবল প্রয়োজন হলে সীমিত-প্রবেশের নথিতে রাখুন। CSV-তে private key, seed phrase, password, login token বা অপ্রয়োজনীয় পরিচয়পত্র থাকবে না।

confirmation card কোনো income certificate নয়। এটি দেখায় পেমেন্টের আগে দুই পক্ষ কী বিষয়ে একমত হয়েছিল। পরে invoice, কাজের প্রমাণ ও payment statement-এর সঙ্গে মিললে এর প্রমাণমূল্য বাড়ে। একা card পেমেন্ট সম্পন্ন, আইনসম্মত বা কর-পরিশোধিত প্রমাণ করে না।

একই ক্লায়েন্ট আবার পেমেন্ট দিলে পুরোনো confirmation কি চলবে?

পুরোনো card-কে নতুন payment-এর shortcut বানাবেন না। নতুন invoice, amount, fee, platform support বা network option বদলাতে পারে। একই client হলেও প্রতিটি payment event-এর জন্য current confirmation দরকার। পুরোনো card reference হিসেবে রাখা যায়, কিন্তু নতুন card-এ check time ও কোন field পুনরায় দেখা হয়েছে তা লিখুন।

যদি কোনো assistant বা team member client-এর সঙ্গে কথা বলেন, কে asset/network দেখেছেন এবং কে invoice মিলিয়েছেন তা record করুন। “অন্যজন নিশ্চয়ই দেখেছে” ধরনের handoff gap-এ ভুল হয়। final send instruction দেওয়ার authority একজন নির্ধারিত reviewer-এর কাছে রাখলে conflicting message কমে। reviewer-ও source screen না দেখে শুধু summary approve করবেন না।

পেমেন্টের নির্দেশনা বদলালে কীভাবে জানাবেন?

চ্যাটে শুধু “নতুন address ব্যবহার করুন” লিখলে পুরোনো ও নতুন নির্দেশনা পাশাপাশি থেকে যায়। পরিবর্তনের বার্তায় পুরোনো instruction-এর version বাতিল, নতুন asset/network, effective time এবং নতুন confirmation reference লিখুন। client-কে নতুন card সম্পূর্ণ পড়ে উত্তর দিতে বলুন। পুরোনো message delete করলেও client copy থেকে মুছে যাবে ধরে নেবেন না।

পরিবর্তনটি address-এর হলেও asset ও network আবার উল্লেখ করুন। এতে client কেবল নতুন string নিয়ে পুরোনো network ধরে পাঠাবে না। কোনো emergency বা deadline এই পুনরায় যাচাই বাদ দেওয়ার কারণ নয়। payment window শেষ হলে নতুন করে শুরু করা ভুল transfer উদ্ধার করার চেয়ে ভালো।

কপি করার মতো non-wallet confirmation card কেমন হবে?

নিচের বার্তাটি সিদ্ধান্ত নথিভুক্ত করার জন্য। এতে কোনো বাস্তব address বসাবেন না; address আলাদা নিরাপদ receive flow থেকে নেওয়া হবে।

Invoice: [invoice number] Asset: USDT Sender network label: [TRC20 / ERC20 / BEP20 / other] Recipient network label: [must match exactly] Amount and unit: [amount] USDT Payment type: [single / installment number] Percentage fee: [known value / unknown] Fixed deduction: [known value / unknown] Network fee bearer: [sender / recipient / unknown] Address source: recipient’s current receive screen; not included in this card After-send evidence: transaction hash, send time, amount and sender reference Stop rule: any asset, network, amount or address mismatch means do not send Regulatory status: confirm the permitted payment route with the recipient’s AD before action

ক্লায়েন্ট “confirmed” বললে card-এর version ও সময় রাখুন। পরে কোনো field বদলালে নতুন version দিন; পুরোনো বার্তা নীরবে edit করবেন না। address আলাদা পাঠানোর মুহূর্তে asset/network label আবার পড়ুন। এতে card পুরোনো হয়ে গেলেও ভুল নির্দেশনা পুনর্ব্যবহারের সম্ভাবনা কমে।

দুইজন মিলে যাচাই করলে দায়িত্ব কীভাবে ভাগ করবেন?

দুইজন reviewer থাকলে একই checklist দুবার অন্ধভাবে টিক দেওয়া দরকার নেই। প্রথম reviewer source screen থেকে asset, network label, receive address ও platform support পড়বেন। দ্বিতীয় reviewer invoice, amount, fee bearer, version time এবং client-এর confirmation মিলাবেন। তারপর দুজন শুধু ফল নয়, তারা কোন evidence দেখেছেন সেটিও লিখবেন। এতে “network অন্যজন দেখেছে” বা “invoice হয়তো ঠিক ছিল” ধরনের অস্পষ্ট handoff কমে।

Review record-এ চারটি ছোট field যথেষ্ট: checked_by, checked_at, evidence_reference, open_question। নামের বদলে team identifier ব্যবহার করা যায়, কিন্তু কে final send instruction দিয়েছেন তা বোঝা দরকার। কোনো reviewer নিজের private key, seed phrase বা login credential দিয়ে যাচাই করবেন না; receive screen দেখা ও secret export করা এক জিনিস নয়। Screen share দরকার হলে sensitive notification, balance, email ও account identifier গোপন রাখুন। সম্ভব হলে শুধু প্রয়োজনীয় public receive information-ই দেখুন।

দুই reviewer-এর ফল না মিললে সংখ্যাগরিষ্ঠতার ভোট নেবেন না। Difference table বানান: একজন কী দেখেছেন, অন্যজন কী দেখেছেন, কোন page version বা time আলাদা এবং কোন official support answer দরকার। Mismatch মিটে না যাওয়া পর্যন্ত card-এর status hold থাকবে। তাড়াহুড়ো করে পুরোনো screenshot বেছে নেওয়া verification নয়। এই পদ্ধতি ছোট team-এর জন্যও কাজে লাগে, কারণ final message পাঠানোর আগে unresolved question দৃশ্যমান থাকে।

ক্লায়েন্টের উত্তরে কোন শব্দগুলো দ্ব্যর্থক হতে পারে?

“Same network”, “usual address”, “send USDT”, “fee included” বা “I already paid”—এই বাক্যগুলো একা যথেষ্ট নয়। Same network বলতে client TRC20 বুঝতে পারে, recipient BEP20; fee included বলতে gross amount নাকি sender fee বোঝানো হয়েছে তা অস্পষ্ট; paid বলতে transaction broadcast, explorer confirmation বা recipient credit—যেকোনোটি বোঝাতে পারে। প্রতিটি দ্ব্যর্থক বাক্যকে measurable field-এ ফেরত নিন। উদাহরণ: “আপনার send screen-এ network label হুবহু কী?”, “500 USDT কি recipient gross amount, নাকি সব deduction-এর পর target?”, “hash ও send time দিন; recipient credit আলাদাভাবে মিলবে।”

Client-এর উত্তর নিজের ভাষায় সংক্ষিপ্ত করে confirmation চাইতে পারেন, কিন্তু তাদের বক্তব্য বদলে দেবেন না। “আপনি ERC20 বলেছেন” লিখে তারা শুধু “yes” বললে version time রাখুন। Voice call-এ সিদ্ধান্ত হলে call শেষে text summary পাঠিয়ে confirmation নিন; গোপনে recording করার নির্দেশ এই checklist দেয় না। Translation ব্যবহার করলে asset symbol, network label, amount, decimal separator ও address কখনো অনুবাদ করবেন না। Bengali ব্যাখ্যার পাশে exact interface label রাখলে দুই ভাষার অর্থ গুলিয়ে যাওয়ার সম্ভাবনা কমে।

ক্লায়েন্ট একই উত্তরে address ও network বদলে দিলে পুরোনো card বাতিল করুন। শুধু changed field patch করলে অন্য পক্ষ কোন version final বুঝতে নাও পারে। নতুন card-এ supersedes reference দিন এবং client-কে সম্পূর্ণ card আবার পড়তে বলুন। এই অতিরিক্ত ধাপ transaction ধীর করতে পারে, কিন্তু অস্পষ্ট instruction দ্রুত পাঠানোর চেয়ে pause করা ভালো।

প্রেরণের ঠিক আগে 60 সেকেন্ডের বিরতিতে কী দেখবেন?

এই বিরতি কোনো countdown নয়; সিদ্ধান্ত থামিয়ে চোখ দিয়ে মূল field আবার পড়ার একটি অভ্যাস। Clipboard-এর address receive screen-এর সঙ্গে প্রথম ও শেষ কয়েকটি অক্ষরসহ মিলান, কিন্তু শুধু ওই কয়েকটি অক্ষর দেখে সম্পূর্ণ match ঘোষণা করবেন না। Asset USDT কি না, network label exact কি না, amount ও decimal ঠিক কি না এবং client কোন fee বহন করবে—একবারে পড়ুন। Browser tab, chat message ও receive screen যেন একই payment event-এর হয় তা নিশ্চিত করুন।

তারপর stop condition বলুন: address বদলেছে, network dropdown অনির্ধারিত, platform warning এসেছে, amount invoice-এর সঙ্গে মেলেনি বা client confirmation পুরোনো version-এর—যেকোনো একটিতে পাঠানো থামবে। “একটু কম amount দিয়ে দেখি” স্বয়ংক্রিয় সমাধান নয়; test payment-ও বাস্তব transfer এবং ভুল network-এ হারাতে পারে। Test ব্যবহারের সিদ্ধান্ত থাকলে তার amount, fee, success criterion ও balance release rule আগে card-এ লিখুন।

শেষে send-এর পর কী সংগ্রহ করবেন তা প্রস্তুত রাখুন: hash, send time, asset, network, amount, sender reference এবং recipient credit status। এগুলো আগে ঠিক না করলে পরে chat ও explorer থেকে টুকরো তথ্য জোড়া লাগাতে হয়। বিরতি successful transfer-এর নিশ্চয়তা দেয় না; এটি ভুল instruction ধরার শেষ manual control। Platform warning বা local regulatory uncertainty থাকলে pause-এর ফল হবে “পাঠাবেন না”, “আরও দ্রুত চেষ্টা করুন” নয়।

Address কপি করার পরে কোন তিন স্তরে মিলাবেন?

প্রথম স্তর source: address কোথা থেকে এসেছে—বর্তমান receive screen, verified invoice portal, নাকি পুরোনো chat? পুরোনো chat বা screenshot থেকে address পুনর্ব্যবহার করবেন না। দ্বিতীয় স্তর syntax: কপি করা string-এ space, line break, truncation বা অন্য character ঢুকেছে কি না দেখুন। এটি কেবল format observation; valid-looking string ownership বা correct network প্রমাণ করে না। তৃতীয় স্তর destination context: receiving platform একই asset-network pair-এর জন্য এই address দেখাচ্ছে কি না এবং কোনো memo/tag প্রয়োজন কি না পড়ুন।

প্রথম ও শেষ কয়েকটি character দেখা একটি সহায়ক check, সম্পূর্ণ comparison-এর বিকল্প নয়। Clipboard malware বা accidental selection মাঝের অংশ বদলাতে পারে। সম্ভব হলে trusted interface-এর built-in copy action ব্যবহার করে destination field-এর সম্পূর্ণ string আবার source-এর সঙ্গে মিলান। QR ব্যবহার করলে scan result text হিসেবে পড়ুন; QR graphic “official দেখায়” বলে বিশ্বাস করবেন না। Address book থাকলেও entry কখন তৈরি হয়েছে, network label কী এবং current receive screen-এর সঙ্গে মেলে কি না যাচাই করুন।

Client-কে address পাঠানোর সময় asset ও network একই message বা signed confirmation card-এ লিখুন। আলাদা message-এ শুধু address পাঠালে তারা পুরোনো network ধরে নিতে পারে। Address বদলালে version number, effective time এবং old version canceled লিখুন। Client old version quote করলে transfer থামান। কোনো address-কে “permanent” বলবেন না, কারণ platform deposit infrastructure বা account state বদলাতে পারে।

Sender ও recipient platform-এর label না মিললে কী করবেন?

এক পাশে “TRX (TRC20)”, অন্য পাশে “TRON” দেখা যেতে পারে; নাম কাছাকাছি হলেও অনুমান করে match করবেন না। উভয় platform-এর current asset/network selection এবং deposit/withdraw notice পড়ুন। Contract address, token issuer ও network documentation প্রাসঙ্গিক হলে official source দিয়ে মিলান, কিন্তু interface support-এর জায়গায় কেবল chain documentation বসাবেন না। Token chain-এ থাকলেই নির্দিষ্ট platform deposit সমর্থন করে—এমন নয়।

এক পাশে network unavailable, maintenance বা suspended দেখালে client-কে অন্য network বেছে নিতে বলার আগে recipient support যাচাই করুন এবং নতুন confirmation card বানান। “BEP20 সস্তা” বা “TRC20 সাধারণ” ধরনের সাধারণ ধারণা destination compatibility প্রমাণ করে না। ERC20 address format ও অন্য EVM network-এর address দেখতে একই হতে পারে; একই string দেখে network same ধরে নেওয়া বিপজ্জনক। Label, chain এবং platform support—তিনটি আলাদা field রাখুন।

Mismatch থাকলে screenshot সংগ্রহের নামে account email, balance, QR, UID বা session তথ্য প্রকাশ করবেন না। Public support article বা redacted interface label যথেষ্ট হতে পারে। Support ticket ব্যবহার করলে ticket reference রাখুন, কিন্তু login link chat-এ পাঠাবেন না। Written confirmation না পাওয়া পর্যন্ত status hold থাকবে।

Test payment ব্যবহার করলে আগে কী লিখবেন?

Test payment ভুল network-কে নিরাপদ করে না; এটি ছোট অঙ্কের বাস্তব transfer। ব্যবহার করার আগে test amount, কে network fee দেবে, success বলতে explorer confirmation নাকি recipient credit বোঝাবে, কতক্ষণ অপেক্ষা করা হবে এবং test সফল হলে balance কখন পাঠানো হবে—সব লিখুন। Test amount invoice total-এর অংশ কি না এবং final balance কীভাবে কমবে তা client agreement-এ স্পষ্ট করুন। না হলে 10 USDT test পাঠানোর পরে client 500 USDT full balance পাঠিয়ে overpayment তৈরি করতে পারে।

Test-এর hash, asset, network, amount, send time, recipient credit ও receiving statement রাখুন। Explorer success কিন্তু recipient credit pending হলে balance পাঠাবেন না। Test wrong asset-এ এলে “অল্প ছিল” বলে ignore করবেন না; mismatch-এর কারণ খুঁজে নতুন instruction দিন। Test fee মোট cost-এ যোগ হবে, তাই single বনাম split comparison-এ এটি বাদ দেওয়া যাবে না।

কোনো platform minimum deposit বা credit rule থাকলে current official display পড়ুন। Minimum-এর নিচে test পাঠালে chain success হলেও platform balance-এ নাও দেখা যেতে পারে; এই সম্ভাবনা fixed number লিখে অনুমান করবেন না। Current rule জানা না থাকলে test plan incomplete। Test সফল হওয়া future transfer guarantee নয়; address, network বা platform status বদলালে আবার full check দরকার।

Client evidence অসম্পূর্ণ হলে কীভাবে follow-up করবেন?

“Proof পাঠান” বললে client screenshot পাঠিয়ে থামতে পারেন। নির্দিষ্ট field চাইুন: transaction hash, asset, exact network label, sent amount, send time with timezone এবং sender reference। Screenshot সহায়ক হতে পারে, কিন্তু hash-এর বিকল্প নয়; আবার hash recipient credit-এর বিকল্প নয়। Client sensitive screen পাঠালে সেটি আর circulate করবেন না, প্রয়োজনীয় field লিখে access সীমিত করুন এবং retention policy অনুযায়ী অপ্রয়োজনীয় copy সরান।

Follow-up message-এ missing field-এর তালিকা ও কেন দরকার এক বাক্যে লিখুন। উদাহরণ: “Hash দরকার যাতে network record দেখা যায়; recipient credit আমরা আলাদাভাবে মিলাব।” Client field দিতে না পারলে invented value বসাবেন না। not provided লিখে discrepancy খোলা রাখুন। Deadline থাকলেও unverified payment-কে complete mark করলে invoice ও income proof পরে ভেঙে যায়।

তৃতীয় পক্ষ payer হলে client relationship ব্যাখ্যা চাইুন। Payer name, client name ও invoice party না মিললে simple note যথেষ্ট কি না তা AD বা পেশাজীবীর current guidance অনুযায়ী দেখুন। এই checklist identity investigation বা private surveillance শেখায় না; উদ্দেশ্য হলো payment record-এর commercial link স্পষ্ট রাখা। Unresolved identity, route বা network প্রশ্ন থাকলে পরবর্তী transfer স্থগিত থাকবে।

Archive handoff-এ কোন জিনিসগুলো আলাদা রাখবেন?

Operational folder-এ confirmation card, invoice reference, hash, status, rate observation ও fee evidence থাকবে। Restricted folder-এ প্রয়োজন হলে client legal identity বা bank correspondence থাকবে। Secret store—যদি থাকে—এই income evidence package-এর বাইরে থাকবে; private key, seed phrase, password, API key, cookie বা login token কোনো archive row-তে লিখবেন না। Public address-ও ব্যবসায়িক প্রয়োজন অনুযায়ী সীমিত করুন, কারণ transaction history থেকে অতিরিক্ত তথ্য বোঝা যেতে পারে।

File name-এ invoice number, event date ও installment id ব্যবহার করুন; “final-final-new” ধরনের নাম এড়ান। একটি index file-এ কোন evidence কোন row সমর্থন করে তা লিখুন। Revision হলে পুরোনো file overwrite না করে version ও correction reason রাখুন। এতে reviewer original claim ও পরে পরিবর্তন আলাদা করতে পারেন।

Handoff-এর সময় receiving reviewer count ও spot-check করবেন: expected installment কত, successful credit কত, duplicate hash আছে কি না, missing field কোনটি এবং unresolved question কে অনুসরণ করবে। Folder পাঠানো মানেই review complete নয়। Access শেষ হলে অপ্রয়োজনীয় share link বন্ধ করুন। Record ভালো হলেও proposed payment route-এর legal status নিজে থেকে প্রমাণিত হয় না; regulatory check আলাদা থাকবে।

শেষবার কোন সাতটি প্রশ্ন করবেন?

1. বাংলাদেশে প্রস্তাবিত পেমেন্ট পথ নিয়ে AD-এর বর্তমান লিখিত ব্যাখ্যা আছে কি?
2. sender ও recipient—দুই পাশে একই asset এবং exact network দেখা যাচ্ছে কি?
3. address বর্তমান receive flow থেকে এসেছে এবং কপি করার পরে মিলেছে কি?
4. invoice, amount, unit ও installment reference স্পষ্ট কি?
5. percentage, fixed এবং network fee কে বহন করবে লেখা আছে কি?
6. পাঠানোর পরে hash, status ও recipient credit কীভাবে মিলবে ঠিক আছে কি?
7. কোনো অমিল হলে “পাঠাবেন না” নিয়ম দুই পক্ষ জানে কি?

একটি প্রশ্নের উত্তরও অস্পষ্ট হলে সেটিই বিরতির কারণ। দ্রুত পাঠানো সফলতার মানদণ্ড নয়; সঠিক asset/network, পুনর্গঠনযোগ্য fee, invoice link, সত্য status এবং প্রযোজ্য নিয়ম মেনে চলাই মানদণ্ড।

সম্পাদকীয় সীমা: এই লেখা প্রযুক্তিগত pre-payment checklist, ব্যক্তিগত আইনগত বা ব্যাংকিং পরামর্শ নয়। বাংলাদেশ ব্যাংকের উৎস 2026-08-10T18:21:00+08:00-এ দেখা হয়েছে। বর্তমান সিদ্ধান্তের জন্য বাংলাদেশ ব্যাংক ও সংশ্লিষ্ট AD-এর লিখিত নির্দেশনা নিন।