বাংলাদেশে পেমেন্ট সিস্টেম চালুর আগে টেস্টিং ও গ্রহণযোগ্যতা যাচাইয়ের চেকলিস্ট

একটি পেমেন্ট সিস্টেমে অর্ডার তৈরি হয়ে সফল দেখালেই সেটি ব্যবসায়িক ব্যবহারের জন্য প্রস্তুত হয় না। গ্রাহকের অর্থপ্রদান, চ্যানেলের প্রতিক্রিয়া, মার্চেন্টের অর্ডার এবং আর্থিক প্রতিবেদনে একই লেনদেনের অবস্থা সামঞ্জস্যপূর্ণ থাকতে হবে। নেটওয়ার্ক বিচ্ছিন্ন হলে, একই নোটিফিকেশন বারবার এলে বা কোনো ফলাফল দেরিতে পৌঁছালে কী হবে, সেটিও আগে জানা জরুরি।

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

১. পরীক্ষার আগে পরিধি ও দায়িত্ব নির্ধারণ করুন

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

BD Payment পেমেন্ট সিস্টেম সফটওয়্যার ভাড়া, ডেপ্লয়মেন্ট এবং প্রযুক্তিগত/API ইন্টিগ্রেশন সেবা প্রদান করে। গ্রাহক নিজস্ব পেমেন্ট চ্যানেল ব্যবহার করেন। BD Payment ব্যাংক অ্যাকাউন্ট, ইলেকট্রনিক ওয়ালেট অ্যাকাউন্ট, পেমেন্ট চ্যানেল, লাইসেন্স বা নিয়ন্ত্রক অনুমোদন প্রদান করে না। ফলে সফটওয়্যার গ্রহণযোগ্যতা এবং চ্যানেল ব্যবহারের প্রস্তুতি আলাদাভাবে যাচাই করতে হবে।

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

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

২. ডেপ্লয়মেন্ট ও পরীক্ষার পরিবেশ যাচাই করুন

স্বতন্ত্র নাকি মাল্টি-টেন্যান্ট ডেপ্লয়মেন্ট?

স্বতন্ত্র ডেপ্লয়মেন্টে অবকাঠামো, রক্ষণাবেক্ষণ ও ডেটা ব্যবস্থাপনার দায়িত্ব স্পষ্ট করা জরুরি। মাল্টি-টেন্যান্ট ব্যবস্থায় বিশেষ গুরুত্ব পাবে পৃথক প্রতিষ্ঠানের ডেটা ও কনফিগারেশন বিচ্ছিন্ন রাখা। BD Payment-এর সঙ্গে উভয় মডেলের উপযোগিতা মূল্যায়ন করা যায়; চূড়ান্ত কাঠামো নির্ভর করবে সম্মত চাহিদা ও বাস্তবায়নের ওপর।

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

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

৩. API ও অর্ডারের পূর্ণ জীবনচক্র পরীক্ষা করুন

শুধু সফল অনুরোধ নয়, ভুল অনুরোধও পাঠান

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

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

অর্ডার স্ট্যাটাসের নিয়ম স্পষ্ট করুন

তৈরি, অপেক্ষমাণ, সফল, ব্যর্থ ও মেয়াদোত্তীর্ণ অবস্থার মধ্যে কোন পরিবর্তন অনুমোদিত, তার মানচিত্র তৈরি করুন। বাহ্যিক চ্যানেলের স্ট্যাটাস কীভাবে অভ্যন্তরীণ স্ট্যাটাসে রূপান্তরিত হবে, সেটিও নথিভুক্ত করুন। একটি বিলম্বিত প্রতিক্রিয়া যেন যাচাই ছাড়া চূড়ান্ত ফলাফল বদলে না দেয়।

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

৪. নিজস্ব চ্যানেল, কলব্যাক ও রাউটিং যাচাই করুন

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

• কলব্যাক প্রমাণীকরণ: চ্যানেলের নির্ধারিত পদ্ধতি অনুযায়ী উৎস ও বার্তার অখণ্ডতা যাচাই হচ্ছে কি?
• পুনরাবৃত্ত নোটিফিকেশন: একই কলব্যাক একাধিকবার এলেও অর্ডার ও হিসাব একবারই আপডেট হচ্ছে কি?
• ক্রমবহির্ভূত বার্তা: পুরোনো অপেক্ষমাণ বার্তা সফল অর্ডারকে পিছিয়ে দিচ্ছে না তো?
• অনুপস্থিত কলব্যাক: প্রযোজ্য হলে স্ট্যাটাস অনুসন্ধান বা ম্যানুয়াল পর্যালোচনায় ফলাফল নিশ্চিত করা যাচ্ছে কি?
• রাউটিং নিয়ম: নির্বাচিত মার্চেন্ট ও অর্ডার নির্ধারিত চ্যানেলেই যাচ্ছে কি?
• চ্যানেল বন্ধ: নিষ্ক্রিয় চ্যানেলে নতুন অনুরোধ বন্ধ হচ্ছে এবং চলমান অর্ডার অনুসরণযোগ্য থাকছে কি?

টাইমআউট মানেই ব্যর্থতা নয়। প্রথম চ্যানেল অনুরোধ গ্রহণ করেছে কি না নিশ্চিত না হয়ে অন্য চ্যানেলে একই লেনদেন পাঠালে দ্বৈত প্রক্রিয়াকরণের ঝুঁকি তৈরি হতে পারে। অনিশ্চিত ফলাফলের জন্য আলাদা তদন্ত ও পুনরায় চেষ্টার নিয়ম রাখুন।

৫. অর্থগ্রহণ, অর্থপ্রেরণ ও স্বয়ংক্রিয় ম্যাচিং পরীক্ষা করুন

অর্থগ্রহণে সঠিক অর্ডার শনাক্ত হচ্ছে কি?

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

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

অর্থপ্রেরণে অনুমোদন ও পুনরাবৃত্তি নিয়ন্ত্রণ

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

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

৬. ফাইন্যান্স রিকনসিলিয়েশন ও রিপোর্ট পরীক্ষা করুন

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

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

এজেন্টভিত্তিক রিপোর্ট বা কমিশনের হিসাব পরিধিতে থাকলে অনুমোদিত কনফিগারেশন অনুযায়ী পরীক্ষা করুন। উদাহরণের জন্য অনুমানভিত্তিক ফি বা হারকে বাস্তব ব্যবসায়িক শর্ত হিসেবে ব্যবহার করবেন না।

৭. মার্চেন্ট, এজেন্ট, অনুমতি ও ঝুঁকি ব্যবস্থাপনা

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

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

সতর্কতা তৈরি হওয়াই যথেষ্ট নয়। কে সেটি দেখবেন, কী তথ্যের ভিত্তিতে সিদ্ধান্ত নেবেন এবং ভুল সতর্কতা কীভাবে নিষ্পত্তি করবেন, সেটিও অনুশীলন করুন।

৮. চাপ, ব্যর্থতা ও পুনরুদ্ধারের পরীক্ষা

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

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

গ্রহণযোগ্য সময়সীমা, পুনরুদ্ধারের লক্ষ্য এবং সহনীয় ডেটা ক্ষতির সীমা সংশ্লিষ্ট পক্ষ আগেই নির্ধারণ করবেন। পরীক্ষা শেষে বাস্তব ফলাফল ওই মানদণ্ডের সঙ্গে তুলনা করুন।

৯. গ্রহণযোগ্যতার প্রমাণ ও গো-লাইভ সিদ্ধান্ত

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

চূড়ান্ত গ্রহণযোগ্যতা যাচাইয়ের চেকলিস্ট

1. সম্মত ব্যবসায়িক কার্যপ্রবাহের গুরুত্বপূর্ণ পরীক্ষাগুলো সম্পন্ন ও অনুমোদিত।
2. সফল, ব্যর্থ, অপেক্ষমাণ, ডুপ্লিকেট ও অনিশ্চিত ফলাফলের আচরণ যাচাই করা হয়েছে।
3. অমীমাংসিত ত্রুটির প্রভাব, সমাধানের দায়িত্ব এবং পুনঃপরীক্ষার পরিকল্পনা নথিভুক্ত।
4. ফাইন্যান্স দল পরীক্ষামূলক লেনদেনের হিসাব ও অমিল নিষ্পত্তি পর্যালোচনা করেছে।
5. প্রোডাকশন সেটিংস, পরিচয়পত্র ও প্রবেশাধিকার চূড়ান্তভাবে যাচাই করা হয়েছে।
6. পর্যবেক্ষণ, সহায়তা যোগাযোগ, ঘটনা ব্যবস্থাপনা এবং রোলব্যাক নির্দেশনা প্রস্তুত।
7. প্রযুক্তি, অপারেশন, ফাইন্যান্স ও ব্যবসায়িক মালিকের লিখিত অনুমোদন সংরক্ষিত।

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

১০. সীমিত চালু ও রোলব্যাক পরিকল্পনা

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

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

সারসংক্ষেপ

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

সাধারণ প্রশ্নোত্তর

১. সফল একটি লেনদেন কি গ্রহণযোগ্যতার জন্য যথেষ্ট?

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

২. BD Payment কি পেমেন্ট চ্যানেল বা অ্যাকাউন্ট দেয়?

না। BD Payment সফটওয়্যার ভাড়া, ডেপ্লয়মেন্ট ও প্রযুক্তিগত/API ইন্টিগ্রেশন দেয়। গ্রাহক নিজের চ্যানেল ব্যবহার করেন। ব্যাংক বা ইলেকট্রনিক ওয়ালেট অ্যাকাউন্ট, চ্যানেল, লাইসেন্স কিংবা নিয়ন্ত্রক অনুমোদন এই সেবার অংশ নয়।

৩. কাস্টম API হলে কি আলাদা পরীক্ষা দরকার?

হ্যাঁ। স্ট্যান্ডার্ড পরীক্ষার পাশাপাশি কাস্টম ফিল্ড, স্ট্যাটাস রূপান্তর, ত্রুটি ব্যবস্থাপনা ও সংস্করণ পরিবর্তনের প্রভাব পরীক্ষা করুন। কাস্টম অংশের কারণে বিদ্যমান কার্যপ্রবাহে সমস্যা হচ্ছে কি না, তা দেখতে রিগ্রেশন টেস্টও দরকার।

৪. স্যান্ডবক্স পরীক্ষা সফল হলে কি সরাসরি চালু করা যাবে?

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

৫. গ্রহণযোগ্যতার চূড়ান্ত অনুমোদন কে দেবেন?

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