মার্চেন্ট ইনিশিয়েটেড ট্রানজ্যাকশন (MIT)

MIT সহায়তা সম্পর্কে এক ঝলকে

মার্চেন্ট ইনিশিয়েটেড ট্রানজ্যাকশন (MIT) হল এমন ট্রানজ্যাকশন যা ব্যবহারকারী অ্যাক্টিভ সেশনে না থাকা সত্ত্বেও প্রসেস করা হয়। Google Pay Online API-তে এই আপডেট এইসব ট্রানজ্যাকশনের ক্ষেত্রে আরও ভাল দৃশ্যমানতা, বিলিংয়ের বিবরণ সংক্রান্ত UX-এর মাধ্যমে ব্যবহারকারীর অভিজ্ঞতা উন্নত করা এবং পেমেন্ট নিরবচ্ছিন্ন রাখার সুবিধা প্রদান করে।

গুরুত্বপূর্ণ ব্যবহারিক ক্ষেত্র

• রেকারিং পেমেন্ট: ডিজিটাল স্ট্রিমিং পরিষেবা, মেম্বারশিপ বা ইউটিলিটি।
• ডেফার করা পেমেন্ট: হোটেল রিজার্ভেশন, প্রি-অর্ডার বা অনুপস্থিত থাকার জন্য ফি।
• অটোমেটিক রিলোড: ট্রানজিট বা গিফ্ট কার্ডের জন্য সেভ করা ভ্যালু টপ-আপ।

MIT API প্রয়োগ করা

MIT API হল আগে থেকে থাকা loadPaymentData API-এর এক্সটেনশন। বিলিং ইনটেন্ট নির্দিষ্ট করতে ইন্টিগ্রেটরদের অবশ্যই একটি *TransactionInfo অবজেক্ট অন্তর্ভুক্ত করতে হবে। মার্চেন্ট ইনিশিয়েটেড ট্রানজ্যাকশনের ধরনের উপর নির্ভর করে Google ৩টি বিকল্প প্রদান করে:

• RecurringTransactionInfo
• DeferredTransactionInfo
• AutomaticReloadTransactionInfo

মনে রাখবেন: এগুলি শুধুমাত্র মার্চেন্ট ইনিশিয়েটেড ট্রানজ্যাকশনের জন্য। অন্যান্য সব ট্রানজ্যাকশন আগেকার TransactionInfo অবজেক্ট ব্যবহার করা চালিয়ে যাবে।

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

ইন্টিগ্রেশন সংক্রান্ত ধাপ

1. ডকুমেন্টেশন: তিনটি নতুন অবজেক্টের সংজ্ঞা ডকুমেন্টেশনের অবজেক্ট রেফারেন্স বিভাগে রয়েছে এবং আগের তালিকায় সরাসরি লিঙ্ক করা আছে।
2. ইমপ্লিমেন্টেশন: আপনার API অনুরোধে আপনার সিস্টেমের জন্য প্রাসঙ্গিক *TransactionInfo অবজেক্ট ব্যবহার করুন।
   • মনে রাখবেন, API-তে প্রতিটি অনুরোধের জন্য শুধুমাত্র একটি অবজেক্ট পাস করা যেতে পারে। কোন অবজেক্ট ব্যবহার করতে হবে এবং ফিল্ড পূরণ করতে হবে তা ব্যক্তিগত মার্চেন্টকে নির্ধারণ করতে হবে।
3. টেস্টিং: বিলিংয়ের বিবরণ পে-শিটে সঠিকভাবে রেন্ডার হচ্ছে কিনা তা যাচাই করতে TEST এনভায়রনমেন্ট ব্যবহার করুন।
4. লঞ্চ করা: প্যারামিটার যাচাই করা হয়ে গেলে লাইভ হন।

মনে রাখবেন: বর্তমানে, মার্চেন্ট ইনিশিয়েটেড ট্রানজ্যাকশনের জন্য ডায়নামিক প্রাইসিং কাজ করে না। এটি একটি পরিচিত সীমাবদ্ধতা।

টোকেন লাইফসাইকেল ম্যানেজমেন্ট (TLM)

টোকেন লাইফসাইকেল ম্যানেজমেন্ট, সুরক্ষিত পেমেন্ট টোকেন আপডেট বা ডিঅ্যাক্টিভেট করা হলে রিয়েল-টাইম বিজ্ঞপ্তি প্রদান করে পেমেন্ট নিরবচ্ছিন্নভাবে হওয়ার বিষয়টি নিশ্চিত করে। সম্পূর্ণ বিবরণের জন্য, টোকেন লাইফসাইকেল ম্যানেজমেন্ট ডকুমেন্টেশন দেখুন।

গুরুত্বপূর্ণ: কোনও নির্দিষ্ট ট্রানজ্যাকশনের ক্ষেত্রে টোকেন লাইফসাইকেল ম্যানেজমেন্ট প্রয়োগ করতে হলে, প্রাসঙ্গিক *TransactionInfo অবজেক্টে tokenUpdateUrl অবশ্যই অন্তর্ভুক্ত থাকতে হবে।

গুরুত্বপূর্ণ টোকেন ইভেন্ট

• বন্ধ করা/মুছে দেওয়া: কোনও টোকেন আর ব্যবহারযোগ্য না থাকলে বিজ্ঞপ্তি পাঠায়।
• FPAN সাফিক্স আপডেট: অন্তর্নিহিত ফান্ডিং প্রাইমারি অ্যাকাউন্ট নম্বর আপডেট করা হলে এটি ঘটে।

সার্ভার সেট-আপ সংক্রান্ত প্রয়োজনীয়তা

সরাসরি মার্চেন্ট ও পেমেন্ট পরিষেবা প্রদানকারী (PSP)-কে অবশ্যই এমন একটি সিস্টেম তৈরি করতে হবে যার মাধ্যমে এইসব মেসেজ গ্রহণ, ডিক্রিপ্ট ও প্রসেস করা যায়।

এই ব্যাজ অর্জন করার জন্য প্রয়োজনীয় যোগ্যতা	বিবরণ
এন্ডপয়েন্ট	POST কল পাওয়ার জন্য সুরক্ষিত HTTPS এন্ডপয়েন্ট।
যাচাইকরণ	অবশ্যই সিগনেচার যাচাইকরণ ও মেসেজ ডিক্রিপশন ম্যানেজ করতে হবে।
উত্তর	বিজ্ঞপ্তি পাঠানো চালিয়ে যেতে SUCCESS রিটার্ন করুন অথবা বন্ধ করতে TOKEN_NOT_FOUND/TOKEN_NOT_IN_USE রিটার্ন করুন।
মার্চেন্ট বিজ্ঞপ্তি	PSPs-কে তাদের মার্চেন্টদের টোকেনের স্ট্যাটাস জানাতে হবে।

প্রয়োগ সংক্রান্ত নোট

টোকেনের আপডেট পেতে হলে, tokenUpdateUrl এন্ডপয়েন্টকে অবশ্যই ট্রানজ্যাকশনের সাথে পাস করতে হবে। PSPs-এর ক্ষেত্রে, মার্চেন্ট কীভাবে এই URL পাবেন এবং প্রাসঙ্গিক *TransactionInfo অবজেক্টে তা পূরণ করবেন তা নির্ধারণ করার দায়িত্ব PSP-র।

এছাড়াও, মনে রাখবেন যে এনক্রিপ্ট করা পেলোড MIT-এর জন্য একটি অতিরিক্ত ঐচ্ছিক ফিল্ড, merchantTokenId রিটার্ন করবে। নির্দিষ্ট বিবরণের জন্য, পেমেন্ট ডেটা ক্রিপ্টোগ্রাফি ডকুমেন্টেশন (মার্চেন্টদের জন্য) অথবা পে-লোড স্ট্রাকচার ডকুমেন্টেশন (PSP-দের জন্য) দেখুন।