এজেন্ট-রেডি চেকআউট: AI যখন ক্রেতার হয়ে কেনে, তখন পেমেন্ট, টোকেন ও আস্থা

মঙ্গলবার সকাল ৯টা ১২। একটি ছোট ইলেকট্রনিকস দোকানের মালিকের কাছে এইমাত্র একজন ক্রেতার AI অ্যাসিস্ট্যান্টের পাঠানো একটি order এসেছে: একটি ল্যাপটপ চার্জার, ৪৯ ডলার, দাম মেটানো হয়েছে ক্রেতার ব্যাংকের দেওয়া একটি tokenে, যা শুধু এই দোকানের জন্য আর ৩০ মিনিট বৈধ। কার্ড নম্বর নেই, account নেই, browser sessionও নেই।

তাঁর fraud নিয়মগুলো সাজানো মানুষের আচরণ ধরে। নতুন device, mouse-এর নড়াচড়া নেই, দুই সেকেন্ডে checkout শেষ: নিয়ম order-টিকে উচ্চ ঝুঁকির ধরে ফিরিয়ে দেয়। একই সকালে যে request শুধু header-এ নিজেকে "agent" বলে দাবি করে, সেটি তাঁর "পরিচিত ভালো automation" নিয়মের ফাঁক গলে ঢুকে যায়। একটি আসল বিক্রি ফিরে গেল, একটি bot ঢুকে গেল। (এটি একটি কাল্পনিক দৃশ্য, কোনো আসল দোকান নয়।)

সমাধান নিয়ম আlogা করা নয়, কড়া করাও নয়। agent-দের কাছে বিক্রি করা checkout তিনটি প্রশ্ন ক্রমানুসারে করে: কে চাইছে, agent-কে কী কেনার অনুমতি দেওয়া হয়েছিল, আর এই order-টি কতটা ঝুঁকিপূর্ণ? এই লেখার বাকি অংশে সেই প্রশ্নগুলোর পেছনের ব্যবস্থাটা বোঝানো হয়েছে।

সিরিজের প্রথম পর্বে প্রশ্ন ছিল, একটি AI agent আপনার দোকান খুঁজে পেয়ে বুঝতে পারবে কি না। দ্বিতীয় পর্বে প্রশ্ন ছিল, অ্যাসিস্ট্যান্ট সেটি সুপারিশ করবে কি না। এই পর্বের প্রশ্নটাই ঠিক করে দেয় টাকা কে পাবে: agent যখন কিনতে প্রস্তুত, তখন আপনার checkout কি নিরাপদে "হ্যাঁ" বলতে পারে? ২০২৬-এর প্রতিটি গুরুত্বপূর্ণ প্রোগ্রাম কার্ডের জায়গায় দিয়েছে একটি সীমিত, বাতিলযোগ্য credential, সঙ্গে ক্রেতা কী অনুমতি দিয়েছেন তার একটি signed নথি। নিচে পাবেন ২০২৬-এর সেপ্টেম্বরের শুরুতে প্রতিটি প্রোগ্রামের অবস্থা, আর আপনার checkout-এ এখনই কী ঠিক করতে হবে তার চেকলিস্ট।

এটি "AI agent-এর কাছে বিক্রি" সিরিজের ৩ নম্বর পর্ব, মোট ৩টির মধ্যে। প্রথম পর্ব: এজেন্টিক কমার্স: পরের ক্রেতা যখন একটি AI agent, তখন বিক্রি করবেন কীভাবে। দ্বিতীয় পর্ব: অনলাইন দোকানের জন্য GEO।

কার্ড না দেখেই agent যেভাবে payment করে

অনলাইনে দাম দিতে গেলে আমরা form-এ ১৬ সংখ্যার নম্বর বসাই। agent-ও তা-ই করলে নম্বরটা মডেল providerের system, log আর memoryতে থেকে যেত। ইন্ডাস্ট্রির সমাধান হলো agent-কে আসল কার্ডের বদলে একটি প্রতিনিধি দেওয়া।

এই প্রতিনিধির নাম tokenাইজড credential। আসল কার্ড ব্যাংক বা walletের কাছেই থাকে। agent পায় এমন একটি token, যা একটি নির্দিষ্ট দোকান, একটি সর্বোচ্চ অঙ্ক আর অল্প সময়ের জন্য বৈধ, এবং ক্রেতা চাইলে যেকোনো সময় বাতিল করতে পারেন। token ফাঁস হলেও হাতে আসে প্রায় খরচ হয়ে যাওয়া একটা অনুমতিপত্র, কার্ড নয়।

token নতুন কিছু নয়। মোবাইল wallet আর সেভ করা কার্ডের পেছনে কার্ড network-গুলো বহু বছর ধরে network token চালাচ্ছে। নতুন হলো tokenের সঙ্গে নিয়ম জুড়ে দেওয়া: agent-টি কে, কী কিনতে পারবে, কতক্ষণ।

২০২৬-এর সেপ্টেম্বরে প্রোগ্রামগুলোর অবস্থা

বেশ কয়েকটি প্রোগ্রাম একে অন্যের সঙ্গে মিলেমিশে আছে, browserের মতো প্রতিদ্বন্দ্বী নয়। কোনোটি ঠিক করে agent দোকানের সঙ্গে কীভাবে কথা বলবে, কোনোটি অনুমতির প্রমাণ, কোনোটি paymentের অনুমোদন। ২০২৬-এর সেপ্টেম্বরের শুরু পর্যন্ত প্রকাশ্য তথ্য এই:

প্রোগ্রাম	কী কভার করে	অবস্থা, সেপ্টেম্বর ২০২৬
Agentic Commerce Protocol (OpenAI ও Stripe)	agent কীভাবে checkout শুরু করে ও বিক্রেতাকে payment token দেয়	২০২৫-এর সেপ্টেম্বরে ওপেন স্ট্যান্ডার্ড হিসেবে প্রকাশিত। ChatGPT-র ভেতরের Instant Checkout ২০২৬-এর মার্চে বন্ধ হয়েছে বলে জানা গেছে, তবে প্রোটোকল চলছে; স্পেকের সর্বশেষ সংস্করণ ২০২৬-এর এপ্রিলের
Stripe Shared Payment Tokens ও Agentic Commerce Suite	নির্দিষ্ট বিক্রেতা, অঙ্ক ও সময়ে সীমিত token	২০২৫-এর ডিসেম্বরে চালু; প্রোটোকলের delegated payment স্পেসিফিকেশন দিয়ে অন্য payment providerও যুক্ত হতে পারে
Agent Payments Protocol, AP2 (Google)	signed mandate, যা প্রমাণ করে ক্রেতা কী অনুমোদন দিয়েছিলেন	২০২৫-এর সেপ্টেম্বরে ঘোষিত; ২০২৬-এর এপ্রিলে মান নির্ধারণের জন্য FIDO Alliance-কে দেওয়া হয়েছে
Universal Commerce Protocol ও Universal Cart (Google)	ক্যাটাlog ও checkout-এর স্ট্যান্ডার্ড, সঙ্গে Search ও Gemini জুড়ে একটি cart	স্ট্যান্ডার্ড ২০২৬-এর জানুয়ারিতে ঘোষিত; cart ঘোষণা হয়েছে মে ২০২৬-এ, গ্রীষ্মে যুক্তরাষ্ট্রে রোলআউটের কথা। পরিকল্পনায় ধরার আগে বর্তমান প্রাপ্যতা দেখে নিন
Visa Intelligent Commerce ও Trusted Agent Protocol	agent token, আর বিশ্বস্ত agent চেনার জন্য signed request	২০২৫-এর অক্টোবরে বিক্রেতা ও প্রসেসর পার্টনারদের সঙ্গে ঘোষিত; developer স্যান্ডবক্স খোলা
Mastercard Agent Pay	বিদ্যমান কার্ড tokenাইজেশনের ওপর agentic token	২০২৬-এর মার্চ থেকে এশিয়া-প্যাসিফিকে প্রথম লাইভ agent paymentের খবর; এর Verifiable Intent ফ্রেমওয়ার্ক FIDO Alliance-কে দেওয়া হয়েছে

আলাদা কোনো সারির চেয়ে দুটি কথা বেশি জরুরি। এক, পুরো কেনাকাটা চ্যাট উইন্ডোর ভেতরে আনার যে উদ্যোগটি সবচেয়ে বড় ছিল, সেটি পিছু হটেছে, কিন্তু তার নিচের অবকাঠামো এগিয়ে চলেছে। দুই, এখন স্ট্যান্ডার্ড সংস্থাগুলো এতে যুক্ত: ২০২৬-এর এপ্রিলে FIDO Alliance ওয়ার্কিং গ্রুপ ঘোষণা করেছে, agent অথেনটিকেশন ও agent-এর শুরু করা কমার্সের জন্য, Google ও Mastercard-এর অবদান থেকে শুরু করে। সাধারণত এর মানে, ক্ষেত্রটি একটি মানের দিকে এগোচ্ছে।

পরিমাণ এখনো ছোট। এমন checkout বানান যা agent-কে নিতে পারে; agent-এর ওপর দাঁড়ানো কোনো আয়ের হিসাব ধরে পরিকল্পনা করবেন না।

mandate: কী অনুমোদন দেওয়া হয়েছিল তার signed রেকর্ড

token বলে "এই credential চার্জ করা যাবে"। কিন্তু কেন তা বলে না। সেই ফাঁক ভরে mandate। এটি ক্রেতার অনুমতির signed রেকর্ড, আর AP2 তাকে তিন ভাগে ভাঙে:

• Intent mandate: ক্রেতা কী চেয়েছেন এবং সীমা কত, যেমন "রানিং শু, ১২০ ডলারের নিচে, শুক্রবারের মধ্যে ডেলিভারি"।
• Cart mandate: agent ঠিক যে cartটি বানিয়েছে, দামসহ, signed, যাতে পরে কেউ কোনো লাইন বদলাতে না পারে।
• Payment mandate: payment network-এ পাঠানো অনুমোদন, যাতে চিহ্নিত থাকে যে agent জড়িত ছিল।

একটা signed ক্রয়াদেশের কথা ভাবুন। ক্রেতা বাজেট অনুমোদন করেন, agent order পূরণ করে, আর সইগুলো দুটোকে বেঁধে রাখে। কয়েক মাস পর dispute এলে "ক্রেতা কি সত্যিই এতে রাজি ছিলেন?" প্রশ্নের পেছনে একটি নথি থাকে।

আপনার checkout-এর জন্য এর মানে কী

ক্রিপ্টোগ্রাফি আপনাকে লিখতে হবে না; সই যাচাই করে আপনার payment provider বা platform। আপনার কাজ হলো সইয়ের ওপর নির্ভর করা data স্থির রাখা: আপনি যে cart ফেরত দেন আর যে cartে চার্জ করেন, দুটো মিলতে হবে, দাম, ট্যাক্স, shipping আর মুদ্রা পর্যন্ত। quote করার পর চুপিসারে মোট বদলে ফেললে এই প্রমাণের ধারা ভেঙে যায়।

গোলমাল হলে খরচ কার

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

network-গুলো কাজ করছে। signed agent পরিচয় আর mandate আছে যাতে ইস্যুয়ার "কার্ডধারীর অনুমোদনে agent-এর মাধ্যমে" আর "ফ্রড"-এর পার্থক্য বুঝতে পারে। একে দিকনির্দেশ ধরুন, নিশ্চয়তা নয়। agent লেনদেন চালু করার আগে আপনার payment providerের শর্ত পড়ে নিন।

একটি উদাহরণ (কাল্পনিক): ক্রেতা agent-কে বললেন "আমার ল্যাপটপের জন্য একটা চার্জার কিনে দাও"। agent ভুল কানেক্টরের মডেল কিনে ফেলল, ক্রেতা চার্জ dispute করলেন। আপনার লিস্টিংয়ে কানেক্টরের ধরন স্পষ্ট লেখা থাকলে এবং cart mandate-এ সেই সময়ে যা দেখানো হয়েছিল তা থাকলে আপনার প্রমাণ শক্ত। লিস্টিং অস্পষ্ট থাকলে dispute জেতা কঠিন, আর দোষটা অনেকটাই আপনার ঘাড়ে পড়ে।

agent-এর যুগে ফ্রড signal ও dispute

বেশির ভাগ ফ্রড system চুপচাপ মানুষের আচরণের ওপর নির্ভর করে: mouseের নড়াচড়া, টাইপের গতি, চেনা device, ব্রাউজিং ইতিহাস। agent-এর এসবের কিছুই নেই। ফলে বৈধ agent-এর order বট-আক্রমণের মতো দেখাতে পারে, আবার সত্যিকারের বট agent-এর মুখোশ পরতে পারে।

নিয়মগুলো চার উপায়ে হালনাগাদ করুন:

• agent কনটেক্সটকে signal ধরুন, ছাড়পত্র নয়। বৈধ mandateসহ যাচাইকৃত agent ঝুঁকি কমায়। শুধু "আমি agent" দাবি করা অযাচাইকৃত request ঝুঁকি বাড়ায়।
• প্রমাণ নিজে থেকেই সংরক্ষণ করুন। mandate বা tokenের রেফারেন্স, quote করা cart, ডেলিভারির নিশ্চিতকরণ আর order-এর দিনে কার্যকর নীতির লেখা রেখে দিন।
• প্রতি mandateের ভেলোসিটি দেখুন। এক জোড়া জুতার mandate থেকে পনেরোটি order আসার কথা নয়।
• report-এ agent-এর order আলাদা রাখুন। order-এর সোর্স রেকর্ড না থাকলে return ও disputeের হার তুলনা করা যায় না।

সবটা জুড়লে একটি agent-order-এর সিদ্ধান্ত দেখতে এমন। পরিচয় আগে, কারণ তা ছাড়া বাকি দুই যাচাইয়ের কোনো মানে থাকে না। mandate না থাকলে বা ঝুঁকির স্কোর বেশি হলে order সরাসরি ফিরিয়ে দিতে হবে, এমন নয়: ক্রেতাকে অনুমোদন দিতে বলা যায়, আর তাতে সন্দেহজনক order নিশ্চিত order-এ বদলে যায়।

ভালো agent-কে স্বাগত, খারাপ বটকে আটকান

অনেক দোকান বটের সমস্যার জবাবে সবাইকে একসঙ্গে ব্লক করে দেয়। যখন প্রতিটি স্বয়ংক্রিয় ভিজিটর ছিল স্ক্র্যাপার, তখন এতে কাজ চলত। এখন কিছু স্বয়ংক্রিয় ভিজিটর ক্রেতার প্রতিনিধি, তাদের ব্লক করা মানে order হারানো।

কার্যকর পথ হলো ট্রায়াজ। প্রথমে দেখুন request-এ যাচাইযোগ্য পরিচয় আছে কি না। Visa-র Trusted Agent Protocol এবং Web Bot Auth প্রস্তাব, দুটোই ব্যবহার করে HTTP message signature: agent প্রতিটি request-এ প্রাইভেট কি দিয়ে সই করে, আর আপনি প্রকাশিত পাবলিক কির বিপরীতে সই মিলিয়ে নেন। ২০২৫-এর অক্টোবরে Cloudflare, Visa ও Mastercard-এর সঙ্গে এই পদ্ধতির সমর্থন ঘোষণা করেছে।

তিনটি লেন

• যাচাইকৃত agent: সই মিলেছে। পণ্য, cart ও checkout-এ অনুমতি দিন, স্বাভাবিক rate limitসহ।
• স্ক্র্যাপার: পরিচয় নেই, কিন্তু আচরণ শুধু পড়ার। পাবলিক পেজ দিন, রেট সীমিত করুন, cart ও checkout-এর endpoint থেকে দূরে রাখুন।
• সন্দেহজনক ফ্রড: পরিচয় নেই, আচরণও অস্বাভাবিক, যেমন কার্ড টেস্টিং বা এক ঠিকানা থেকে অনেক cart। চ্যালেঞ্জ করুন বা ব্লক করুন।

robots নিয়ম আর বট-সুরক্ষার settings-ও আরেকবার দেখুন। checkout-এ "browser ছাড়া সব user agent ব্লক" নিয়ম থাকলে সেটি হয়তো এখনই বৈধ agent-দের ফিরিয়ে দিচ্ছে।

নিশ্চিতকরণ, রসিদ ও return

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

• মেশিন-পাঠযোগ্য কনফার্মেশন: order নম্বর, আইটেম, মোট, ট্যাক্স, ডেলিভারির আনুমানিক সময় আর status link, order সম্পূর্ণ হওয়ার একই responseে।
• email রসিদ যাবে ক্রেতার কাছেই। agent ফরওয়ার্ড করবে ভেবে বসে থাকবেন না। ক্রেতার আসল ঠিকানা ব্যবহার করুন, পরে যে রিলে ঠিকানায় পৌঁছাতে পারবেন না তা নয়।
• কাঠামোবদ্ধ status: paid, packed, shipped, delivered, tracking লিংকসহ, যাতে "আমার order কোথায়?" প্রশ্নের এমন উত্তর থাকে যা agent নিজে এনে দিতে পারে।
• agent যে return শুরু করতে পারে: কারণ কোডসহ নথিভুক্ত return request, যোগ্যতা যাচাই, আর মূল paymentে ফেরত যাওয়া refund পদ্ধতি।

refundে বাড়তি যত্ন দরকার। মূল payment সীমিত tokenে হয়ে থাকলে হাতে transfer না করে নিজের providerের মাধ্যমে একই payment মাধ্যমে ফেরত দিন।

আপনার checkout-এ এখনই কী ঠিক করবেন

এজন্য এই ত্রৈমাসিকেই সব প্রোটোকল নিতে হবে, তা নয়। দরকার এমন একটি পরিষ্কার checkout, যাতে পরে যেকোনো একটি নেওয়া ছোট প্রকল্প হয়। তালিকাটি ক্রমানুসারে এগোন।

1. পরিষ্কার order API দিন। cart তৈরি, cart আপডেট, shipping ও ট্যাক্স quote, order সম্পূর্ণ, order status পড়া, প্রতিটির স্থিতিশীল endpoint আর পড়ার মতো error মেসেজ।
2. quoteকে বাধ্যতামূলক করুন। quote করা দাম, ট্যাক্স ও shipping আর চার্জ করা অঙ্ক সমান হবে, আর নির্দিষ্ট সময় পর মেয়াদ শেষ হবে।
3. গেস্ট checkout চালু রাখুন। account খোলা বাধ্যতামূলক করলে সেই ক্রেতার agent আটকে যায়, যিনি কখনো আপনার দোকানে আসেননি।
4. tokenাইজড ও delegated payment সমর্থন করে এমন payment provider নিন। জিজ্ঞেস করুন কোন agent প্রোগ্রাম সমর্থন করে আর সেগুলোর dispute কীভাবে সামলায়।
5. order-এর সোর্স রেকর্ড করুন। agent-উৎস সহ চ্যানেল অনুযায়ী order ট্যাগ করুন, আর token বা mandateের রেফারেন্স রেখে দিন।
6. নীতি স্পষ্ট করে প্রকাশ করুন। ডেলিভারির সময়, return-এর মেয়াদ, refundের পদ্ধতি, নিয়ম আকারে লিখুন, স্লোগান আকারে নয়।
7. ভালো traffic আলাদা করুন। signed agent যাচাই করুন, বাকিদের rate limit বা চ্যালেঞ্জ করুন, সবাইকে ব্লক করবেন না।
8. কাঠামোবদ্ধ নিশ্চিতকরণ ও status আপডেট পাঠান। একই তথ্য, মানুষের জন্য এক রূপে, মেশিনের জন্য আরেক রূপে।
9. স্যান্ডবক্সে পরীক্ষা করুন। Visa, Stripe ও অন্যরা test এনভায়রনমেন্ট দেয়; আসল টাকা চলার আগে পুরো agent কেনাকাটা, একটি refund আর একটি dispute চালিয়ে দেখুন।
10. পর্যালোচনার তারিখ ঠিক করুন। বারো মাসে এই ক্ষেত্র কয়েকবার বদলেছে; প্রতি ত্রৈমাসিকে প্রোগ্রামের অবস্থা দেখে নিন।

এই সিরিজ আপনাকে কোথায় পৌঁছে দিল

তিনটি পর্ব একসঙ্গে একটি ছবি আঁকে। agent-কে আপনাকে খুঁজে পেতে হবে (প্রথম পর্ব), বেছে নিতে হবে (দ্বিতীয় পর্ব), আর checkout সারাতে কোনো মানুষকে ডাকা ছাড়াই দাম মেটাতে পারতে হবে (এই পর্ব)। তিনটির মূল সুতো একটাই: যে তথ্যের পেছনে আপনি দাঁড়াতে পারেন, যেমন নির্ভুল পণ্যতথ্য, নির্দিষ্ট নীতি, বাধ্যতামূলক quote, আর প্রতিটি ক্রেতা কী অনুমতি দিয়েছেন তার রেকর্ড।

৯টা ১২-র সেই দোকানমালিকের দিনটা এবার অন্যরকম। তিনটি যাচাই বসার পর ৪৯ ডলারের চার্জারের order চলে অন্য পথে। সই মিলে যায়, mandate (একটি চার্জার, সর্বোচ্চ ৬০ ডলার) cart ঢেকে রাখে, আর বৈধ mandate ঝুঁকির স্কোরে তাঁর পক্ষে কাজ করে। চার্জ যায় তাঁর নিজের payment providerের মাধ্যমে, আর নিশ্চিতকরণ কয়েক সেকেন্ডের মধ্যে পৌঁছে যায় ক্রেতার অ্যাসিস্ট্যান্টে ও ইনবক্সে।

যে request শুধু নিজেকে agent বলে দাবি করেছিল, সে প্রথম যাচাইতেই আটকে যায়, cartের ধারেকাছেও পৌঁছায় না। তাঁর নিয়ম কড়াও হয়নি, আlogাও হয়নি। সেগুলো নির্দিষ্ট হয়েছে: মানুষ কীভাবে ক্লিক করত তা না দেখে এখন দেখে কে চাইছে আর তার কী করার অনুমতি ছিল।

মূল কথাগুলো

• agent কার্ড নম্বর নয়, সীমিত ও বাতিলযোগ্য token দিয়ে payment করে, আর signed mandateে লেখা থাকে ক্রেতা কী অনুমতি দিয়েছেন।
• ২০২৬-এর সেপ্টেম্বর পর্যন্ত ক্ষেত্রটি FIDO Alliance-এর মাধ্যমে অভিন্ন স্ট্যান্ডার্ডের দিকে এগোচ্ছে; OpenAI-র চ্যাটের ভেতরের Instant Checkout ২০২৬-এর মার্চে বন্ধ হয়েছে বলে জানা গেছে, আর মূল প্রোটোকল চলছে।
• agent-এর কেনাকাটার দায় এখনো মীমাংসিত নয়, তাই শক্ত প্রমাণ রাখুন: quote করা cart, token বা mandateের রেফারেন্স, নীতি আর ডেলিভারির প্রমাণ।
• স্বয়ংক্রিয় traffic-কে যাচাইকৃত পরিচয় দিয়ে ট্রায়াজ করুন: যাচাইকৃত agent-কে ঢুকতে দিন, স্ক্র্যাপারের রেট সীমিত করুন, ফ্রড ব্লক করুন।
• বাধ্যতামূলক quote, গেস্ট checkout, পরিষ্কার order API আর কাঠামোবদ্ধ status, যে প্রোটোকলই জিতুক, এই সংশোধনগুলো কাজে লাগবে।
• প্রতি ত্রৈমাসিকে প্রোগ্রামের অবস্থা আবার দেখুন, আর লাইভ হওয়ার আগে স্যান্ডবক্সে পরীক্ষা করুন।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP system ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, dataর নির্ভুলতা আর নিজের সার্ভারে চালানো systemের ওপর।