Agent-Ready Checkout: মোট দাম Approve করুন, তারপর Payment যাচাই

ক্রেতা assistant-কে compatible laptop charger কিনতে বললেন, সর্বোচ্চ 60-এর মধ্যে। Product 49, shipping 6, ধরা tax 11; মোট 66। এখানে আগে agent-payment problem নয়, budget-এর বাইরের offer ধরা পড়েছে। একই অনির্দিষ্ট মুদ্রায় এটি শিক্ষামূলক হিসাব; tax recommendation নয়।

এবার ধরুন, supported route-এ ক্রেতা নতুন 66-total purchase approve করলেন। Payment request timeout হল। Payment ব্যর্থ, নাকি provider charge করেছে কিন্তু response হারিয়েছে? “আবার চেষ্টা করুন” বিপজ্জনক, যদি তার মানে হয় নতুন payment তৈরি।

Protocol logo-র তালিকার চেয়ে এই দুই মুহূর্ত agent-ready checkout ভালো বোঝায়। আগে current purchase-এর অনুমতি নিশ্চিত করুন; তারপর কী ঘটেছে জানুন। নিচের electronics shop কাল্পনিক শিক্ষামূলক উদাহরণ, live sales result নয়।

শুধু Item নয়, পুরো Purchase-এর Quote দিন

আগের 60 limit দিয়ে 66 final total কভার হয় না; ব্যবধান 6। Limit-কে চুপচাপ item-only budget বলবেন না, payment ভাগ করে পাশ কাটাবেন না। অনুমোদিত বিকল্প দেখান বা প্রয়োজনীয় নতুন approval নিন। Delivery, quantity, connector, currency বা seller বদলালেও অনুমোদিত বিষয় বদলাতে পারে।

Quote-এ exact variant ও device compatibility requirement, item amount, discount, tax, shipping, currency, delivery estimate ও অন্য applicable charge রাখুন। Validity ও stock reservation condition বলুন। প্রাসঙ্গিক শর্ত বদলালে পুরোনো quote charge না করে revalidate ও authority refresh করুন। Cart একা stock reservation নয়।

সব buyer-এর route এক নয়। নিজের checkout page-এ approval, cart transfer বা eligible in-assistant integration হতে পারে। Google-এর native-checkout guide supported lifecycle বলে, universal enrolment নয়। নিজের merchant-এর route ও version যাচাই করুন।

Trust-এর চারটি প্রশ্ন আলাদা করুন

Caller চেনা, ক্রেতার authority প্রমাণ, valid credential ব্যবহার ও transaction risk দেখা সম্পর্কিত পরীক্ষা; একটি আরেকটির বিকল্প নয়। Table-এ আলাদা আছে। Genuine agent-ও unauthorised purchase চাইতে পারে; buyer approve করলেও normal control-এ refuse করা লাগতে পারে।

AP2 mandate model সরাসরি cart approval ও পরে কাজের delegated instruction আলাদা করে। প্রকৃত supported mandate ও limit মানুন; chat transcript একা verified mandate নয়।

FIDO-র April 2026 announcement AP2 ও Verifiable Intent contribution নিয়ে standards-development কাজের কথা বলে। সব merchant integration এখন interoperable—এমন certificate নয়।

প্রশ্ন	কোন Evidence দেখবেন	কিসের বিকল্প নয়
কে Request করছেন?	Supported caller/session verification	Buyer authority বা সব endpoint-এর permission
ক্রেতা কী অনুমতি দিয়েছেন?	বর্তমান exact cart বা scoped delegation	Payment processing ও fraud control
Credential ব্যবহার করা যাবে?	Provider-validated scope, amount, validity	Product suitability বা সব customer intent
Transaction-এ কী ঘটেছে?	Verified provider ও merchant record	একা settlement, delivery বা dispute result

Token Access সীমিত করে, সব প্রমাণ করে না

Stripe-এর বর্তমান seller guide seller-scoped Shared Payment Token-এর usage ও expiry limit জানায়; recurring configuration-ও আছে। সবার token bank-issued, একবারের ও ত্রিশ মিনিটের ধরে নেবেন না।

কোন provider grant validate করে, কোন seller/currency, কত amount ও কী use condition আছে, expiry/revocation integration-এ কীভাবে enforce হয়—জানুন। Credential-কে approved purchase ও current account permission-এর সঙ্গে মেলান। Valid credential একা product compatibility বা intended quantity প্রমাণ করে না।

Credential prompt, model memory, screenshot, analytics ও সাধারণ log থেকে দূরে রাখুন। প্রয়োজনীয় protected reference ও evidence-ই retention policy অনুযায়ী রাখুন। Tokenization access control, secure handling বা এই flow-এর payment-compliance duty সরায় না। নিজে cryptography বানানোর বদলে supported provider library নিন।

Timeout মানে Reconcile না হওয়া পর্যন্ত Unknown

Consequential request-এর আগে durable local operation reference বানিয়ে approved order ও payload-এর সঙ্গে বাঁধুন। একই operation retry নতুন charge হবে না। Concurrent request-এও local duplicate protection চাই; প্রতি click-এ new key দিলে উদ্দেশ্যটাই ব্যর্থ।

Timeout-এর পরে existing provider/session reference খুঁজে authenticated evidence process করুন। এখনও unknown হলে state রাখুন, ক্রেতাকে জানান; backoff, jitter, attempt limit ও owner-সহ bounded reconciliation queue করুন। Request শেষ হয়েছে বলেই payment failed বলবেন না, সব safeguard ছাড়বেন না বা দুবার fulfil করবেন না।

Stripe-এর idempotency rule API version অনুযায়ী আলাদা: v1 saved server error ফেরাতে পারে; pruned key-তে নতুন request হতে পারে। Error এড়াতে অন্ধভাবে key পাল্টাবেন না।

Payment authorisation, capture, merchant order acceptance, settlement ও fulfilment আলাদা। Screen-এর success বা assistant-এর “paid” একমাত্র evidence নয়। Stripe webhook guide signature verify ও duplicate/out-of-order event সামলাতে বলে। প্রকৃত provider state যাচাই করুন; local effect নিরাপদে repeat হতে পারবে।

Fraud Check ও Customer Permission রাখুন

Supported trust scheme-এ signed request caller চিনতে সাহায্য করে। Product, order ও payment endpoint-এ allow-all rule নয়। প্রযোজ্য expected issuer/key, audience ও freshness এবং endpoint-এর current permission/limit যাচাই করুন। বানানো “AI agent” header কোনও প্রমাণ নয়।

Mouse movement নেই—শুধু এটি দিয়ে সিদ্ধান্ত না নিয়ে relevant fraud signal দেখুন। Verified agent-ও transaction check পেরোবে; unverified automation মানেই fraud নয়। Case অনুযায়ী deny, supported additional verification বা normal authorised route দিন। Human confirmation legal prohibition, stolen credential বা unresolved security failure বাতিল করে না।

Status ও return action verified buyer/authorised representative এবং সঠিক account/order-এ সীমিত করুন। Private stock, address, invoice ও payment data public discovery response-এ নয়। Safe rate limit, replay, velocity ও একটি approval দিয়ে বহু order-এর চেষ্টা দেখুন।

Receipt থেকে Return ও Dispute পর্যন্ত Evidence রাখুন

Buyer ব্যবহার করতে পারেন এমন route-এ actual order reference, item, total, currency ও current status জানান। সম্মত support/contact path দিন; legitimate relay address মানেই invalid নয়। Receipt পৌঁছাতে শুধু assistant-এর ওপর নির্ভর করবেন না। Tracking বা shipped status delivery proof নয়।

Return-এ applicable policy, legal right, received goods ও authorised remedy-কে payment operation থেকে আলাদা যাচাই করুন। Stripe refund guide original method-এ টাকা ফেরায় এবং failed refund/permitted alternative আলাদা করে। অপরিচিত transfer বানানোর বদলে documented exception process মানুন।

Approved quote/version, authority reference, provider reference, relevant policy, communication ও fulfilment evidence restricted access-এ রাখুন। Usable token audit attachment নয়। Refund/dispute overlap দেখে double reimbursement এড়ান; refund-এর final result reconcile করুন।

নিজের programme-এ dispute type, authentication step, evidence deadline ও liability condition কে সামলায়, acquirer/provider-কে জিজ্ঞাসা করুন। Signed mandate উপকারী evidence হতে পারে; dispute জেতা বা সব loss transfer নিশ্চিত করে না। Marketing announcement দিয়ে universal liability rule বানাবেন না।

বাড়ানোর আগে Failure Path নিয়ে Pilot করুন

Eligible sandbox ও approved test identity নিন, production card detail নয়। 60 limit-এর বিপরীতে 66 total, approval-এর পর changed cart, expired/revoked credential, wrong seller/currency, duplicate completion, provider success-এর পর timeout, delayed/replayed event, incompatible product, private status ও partial refund/dispute overlap test করুন।

Operator-কে end-to-end record দেখাতে বলুন: একটি approved purchase, intended payment outcome, একটি fulfilment decision ও traceable customer remedy। Unknown payment-এর response deadline, escalation ও stop condition দিন। Sandbox pass live market eligibility বা সব issuer behaviour প্রমাণ করে না; provider-এর সঙ্গে আলাদা নিশ্চিত করুন।

Approved attempt, successful capture, unknown outcome, duplicate incident, fulfilment error, support workload ও refund/dispute নির্দিষ্ট denominator ও observation window দিয়ে মাপুন। Order ও টাকা মেলাতে এবং failure recover করতে পারলেই বাড়ান। উপকারী প্রতিশ্রুতি controlled purchase journey; যেকোনও মূল্যে autonomous sale নয়।

AI shopping series-এর তৃতীয় পর্ব। সঙ্গে পড়ুন purchase route ও merchant readiness এবং product discovery ও GEO।

পর্যালোচনা: ৫ নভেম্বর ২০২৬। Anichur Rahaman StoreConsole-এর নির্মাতা। দৃশ্য ও amount উদাহরণ; programme terms ও supported capability ভিন্ন হয়।