API অর্ডার সম্পন্ন হওয়ার বিজ্ঞপ্তি কীভাবে সেট করবেন

কোন ইভেন্টগুলোকে অর্ডার সম্পন্ন হওয়া হিসেবে গণ্য করবেন

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

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

স্ট্যাটাসের ম্যাপিং টেবিল তৈরি করুন

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

• pending, created, queued — নতুন বা প্রক্রিয়াকরণের অপেক্ষায় থাকা অর্ডার।
• processing, in_progress, running — অর্ডার সম্পাদিত হচ্ছে।
• completed, delivered, success — সম্পন্ন অর্ডার।
• partial, partially_completed — আংশিক সম্পন্ন অর্ডার।
• cancelled, rejected, failed — বাতিল বা ত্রুটিতে শেষ হওয়া অর্ডার।
• refunded, returned — অর্ডারের ফেরত বা সমন্বয় প্রয়োজন।
• অজানা স্ট্যাটাস — কার্ডটি স্বয়ংক্রিয়ভাবে পরিবর্তন করে না এবং যাচাইয়ের জন্য পাঠানো হয়।

উপরের নামগুলো একটি উদাহরণ স্কিমা হিসেবে দেওয়া হয়েছে। চূড়ান্ত টেবিল নির্দিষ্ট API-এর স্ট্যাটাস অনুযায়ী তৈরি করতে হবে। ম্যানুয়াল ম্যাপিংয়ের অসুবিধা হলো API আপডেটের পরে এটি রক্ষণাবেক্ষণ করতে হয়: একটি নতুন স্ট্যাটাস তার জন্য নিয়ম তৈরি হওয়ার আগেই হ্যান্ডলারে পৌঁছে যেতে পারে।

ওয়েবহুক, API পোলিং বা উভয় স্কিমা বেছে নিন

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

• ওয়েবহুক দ্রুত প্রতিক্রিয়ার জন্য উপযুক্ত: কার্ড আপডেট, পরবর্তী ধাপ শুরু করা বা দায়িত্বপ্রাপ্ত ব্যক্তিকে বার্তা পাঠানো।
• পোলিং উপযুক্ত যদি সরবরাহকারী callback-বিজ্ঞপ্তি সমর্থন না করে বা সার্ভার বাহ্যিক অনুরোধ গ্রহণ না করে।
• সম্মিলিত স্কিমা ওয়েবহুককে প্রধান চ্যানেল হিসেবে ব্যবহার করে, আর পোলিং — মিস হওয়া বা আটকে থাকা অর্ডার খুঁজতে।

পোলিংয়ের অসুবিধা হলো বিলম্ব এবং API-তে অতিরিক্ত লোড। ওয়েবহুকের অসুবিধা হলো endpoint সুরক্ষিত করতে হবে, ডুপ্লিকেট বিবেচনা করতে হবে এবং ইভেন্ট ডেলিভারির ক্রমের উপর নির্ভর করা যাবে না।

ইভেন্ট গ্রহণের জন্য endpoint সেট করুন

বিজ্ঞপ্তির জন্য একটি পাবলিক HTTPS ঠিকানা প্রয়োজন, যা API সার্ভিসের পক্ষ থেকে অ্যাক্সেসযোগ্য। ইন্টিগ্রেশন সেটিংসে সাধারণত হ্যান্ডলারের URL, স্বাক্ষর সিক্রেট এবং ইভেন্টের তালিকা নির্দিষ্ট করা হয়: স্ট্যাটাস পরিবর্তন, সম্পন্ন হওয়া, বাতিল, ত্রুটি বা আংশিক সম্পাদন।

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

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

অর্ডার এবং ইভেন্টের মধ্যে সংযোগ সংরক্ষণ করুন

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

যদি API তৈরি করার সময় বাহ্যিক আইডেন্টিফায়ার পাঠানোর অনুমতি দেয়, তাহলে external_id বা client_reference-এর মতো ফিল্ডে আপনার অর্ডার নম্বর যোগ করুন। এটি লগে খোঁজা এবং বিতর্কিত পরিস্থিতি বিশ্লেষণ সহজ করে। তবে বাহ্যিক নম্বরকে একমাত্র কী বানাবেন না: কিছু সরবরাহকারী প্রতিটি বিজ্ঞপ্তিতে এটি ফেরত দেয় না।

ওয়েবহুক থেকে অজানা ID দিয়ে নতুন অর্ডার তৈরি করবেন না। অজানা ইভেন্ট লগে সংরক্ষণ করতে হবে এবং আলাদাভাবে যাচাই করতে হবে। স্বয়ংক্রিয়ভাবে রেকর্ড তৈরি করা ভুল ডেটা বা জাল অনুরোধ প্রক্রিয়াকরণের দিকে নিয়ে যেতে পারে।

স্পষ্ট payload কাঠামো ব্যবহার করুন

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

{

  "event_id": "evt_7f31",

  "event_type": "order.status_changed",

  "created_at": "2025-01-15T12:40:00Z",

  "data": {

    "order_id": "provider_order_4815",

    "external_id": "internal_order_9021",

    "status": "completed",

    "completed_quantity": 1000,

    "requested_quantity": 1000

  }

}

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

মূল অনুরোধ বডি দ্বারা স্বাক্ষর যাচাই করুন

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

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

শর্তসাপেক্ষ উদাহরণ: HMAC_SHA256(সিক্রেট, raw_body) = X-Signature হেডার থেকে স্বাক্ষর। হেডারের নাম, অ্যালগরিদম এবং ফলাফলের ফরম্যাট শুধুমাত্র API ডকুমেন্টেশন থেকে নিতে হবে। কিছু সার্ভিস স্বাক্ষরের স্ট্রিংয়ে টাইমস্ট্যাম্প বা ইভেন্ট ID যোগ করে। এই ক্ষেত্রে শুধু JSON বডি যাচাই করা যাবে না।

স্বাক্ষর যাচাইয়ের আগে JSON পরিবর্তন করবেন না

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

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

এই স্কিমার অসুবিধা হলো হ্যান্ডলার middleware-এর ক্রমের উপর নির্ভরশীল হয়ে পড়ে। ভুল কনফিগারেশনে অ্যাপ্লিকেশন শুধু রূপান্তরিত অবজেক্ট দেখবে, এবং বৈধ বিজ্ঞপ্তি প্রত্যাখ্যান হতে শুরু করবে।

HMAC যাচাই সহ হ্যান্ডলারের উদাহরণ

নিচে Python-এ একটি শর্তসাপেক্ষ উদাহরণ। এটি ক্রিয়াকলাপের ক্রম দেখায়, রেডিমেড ইন্টিগ্রেশন নয়: হেডার, অ্যালগরিদম, স্বাক্ষরের ফরম্যাট এবং payload ফিল্ড সরবরাহকারীর ডকুমেন্টেশন থেকে মান দিয়ে প্রতিস্থাপন করতে হবে।

import hmac

import hashlib

import json

from hmac import compare_digest

def handle_webhook(request):

  raw_body = request.body

  received_signature = request.headers.get("X-Signature", "")

  secret = get_webhook_secret()

  expected_signature = hmac.new(

    secret.encode("utf-8"), raw_body, hashlib.sha256

  ).hexdigest()

  if not compare_digest(expected_signature, received_signature):

    log_invalid_signature(request)

    return response(status=401)

  payload = json.loads(raw_body.decode("utf-8"))

  return process_event(payload)

তুলনার জন্য এমন একটি ফাংশন ব্যবহার করুন যা প্রথম অমিল অক্ষরে কাজ বন্ধ করে না। এটি প্রতিক্রিয়ার সময়ের মাধ্যমে স্বাক্ষরের ডেটা ফাঁসের ঝুঁকি কমায়। সিক্রেট ক্লায়েন্ট কোডে পাঠাবেন না, URL-এ যোগ করবেন না এবং সম্পূর্ণভাবে লগে লিখবেন না।

ইভেন্ট প্রক্রিয়াকরণ আইডেম্পোটেন্ট করুন

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

আইডেম্পোটেন্সি মানে একই ইভেন্ট ফলাফল শুধুমাত্র একবার পরিবর্তন করে। এই নিয়ম বিবেচনা না করলে, ডুপ্লিকেট ক্লায়েন্টকে আবার বার্তা পাঠাবে, ম্যানেজারের জন্য একাধিক কাজ তৈরি করবে, ক্ষতিপূরণ যোগ করবে বা পুনরায় অপারেশন শুরু করবে।

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

একটি অপারেশনে ইভেন্ট এবং স্ট্যাটাস সংরক্ষণ করুন

"ইভেন্ট প্রক্রিয়া হয়েছে কিনা" যাচাই এবং ফলাফল লেখা পারমাণবিকভাবে সম্পাদন করতে হবে। অন্যথায় একই সাথে আসা দুটি অভিন্ন অনুরোধ উভয়ই রেকর্ডের অনুপস্থিতি দেখবে এবং ক্রিয়া দুবার শুরু করবে। একটি ব্যবহারিক বিকল্প হলো event_id-এ অনন্য ইনডেক্স এবং ডেটাবেস ট্রানজ্যাকশন।

হ্যান্ডলারের শর্তসাপেক্ষ ধারাবাহিকতা এরকম:

def process_event(payload):

  event_id = payload["event_id"]

  provider_order_id = payload["data"]["order_id"]

  new_status = map_status(payload["data"]["status"])

  with database_transaction():

    if event_exists(event_id):

      return response(status=200)

    order = find_order_by_provider_id(provider_order_id)

    if order is None:

      save_unmatched_event(event_id, payload)

      return response(status=200)

    apply_status_if_allowed(order, new_status, payload)

    save_processed_event(event_id, provider_order_id)

  enqueue_follow_up_actions(event_id)

  return response(status=200)

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

ইভেন্টের ক্রম লঙ্ঘন বিবেচনা করুন

ওয়েবহুক সবসময় স্ট্যাটাস পরিবর্তনের সময় অনুযায়ী কঠোরভাবে আসে না। প্রথমে সম্পন্ন হওয়ার ইভেন্ট আসতে পারে, তারপর — "চলমান" স্ট্যাটাসের বিলম্বিত বিজ্ঞপ্তি। যদি শুধু সর্বশেষ প্রাপ্ত মান লেখা হয়, সম্পন্ন অর্ডার আবার সক্রিয় হয়ে যাবে।

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

যদি payload-এ অর্ডার পরিবর্তনের সময় থাকে, ঠিক সেটিই তুলনা করুন, ওয়েবহুক পাওয়ার সময় নয়। যখন API এমন মার্কার পাঠায় না, তখন স্টেটের অগ্রাধিকার এবং অর্ডার পাওয়ার পদ্ধতির মাধ্যমে মিলিয়ে দেখা ব্যবহার করুন। অগ্রাধিকারের অসুবিধা — তারা প্রকৃত ক্রম প্রতিস্থাপন করে না, বিশেষত যদি সরবরাহকারী চূড়ান্ত স্ট্যাটাস থেকে ফেরতের অনুমতি দেয়।

দ্রুত ডেলিভারি নিশ্চিত করুন এবং ক্রিয়া সারিতে সরান

সরবরাহকারীকে উত্তর দেওয়ার আগে দীর্ঘ অপারেশন সম্পাদন করবেন না। স্বাক্ষর যাচাই, অর্ডার খোঁজা, ইভেন্ট লেখা এবং স্ট্যাটাস আপডেট সাধারণত দ্রুত সম্পন্ন করা যায়। বার্তা পাঠানো, CRM-এর সাথে সিঙ্ক্রোনাইজেশন, রিপোর্ট তৈরি বা তৃতীয় পক্ষের সিস্টেমে অনুরোধ কাজের সারিতে পাঠানো ভালো।

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

সারির অসুবিধা — একটি আলাদা কম্পোনেন্ট যোগ হয় যা নিয়ন্ত্রণ করতে হবে: কাজের ত্রুটি, বিলম্ব এবং পুনরায় চালু। তবে ম্যানেজারের বিজ্ঞপ্তিতে ব্যর্থতা অর্ডার স্ট্যাটাস গ্রহণ ব্লক করে না।

দল এবং ক্লায়েন্টের জন্য বিজ্ঞপ্তি সেট করুন

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

• সম্পন্ন অর্ডার — ব্যক্তিগত অ্যাকাউন্টে আপডেট বা ক্লায়েন্টকে সংক্ষিপ্ত বার্তা।
• সম্পাদন ত্রুটি — API যে কারণ পাঠিয়েছে তা সহ দায়িত্বপ্রাপ্ত ব্যক্তিকে বিজ্ঞপ্তি।
• আংশিক সম্পাদন — সমন্বয়, ফেরত বা পরবর্তী ক্রিয়ার যাচাইয়ের কাজ।
• অজানা স্ট্যাটাস — লগে রেকর্ড এবং প্রযুক্তিগত বিশেষজ্ঞকে বার্তা।
• অজানা অর্ডার ID — আপনার সিস্টেম এবং সরবরাহকারীর মধ্যে সংযোগের আলাদা যাচাই।

প্রতিটি প্রযুক্তিগত রূপান্তরে বার্তা পাঠাবেন না। ফিড দ্রুত শব্দে পরিণত হবে, এবং গুরুত্বপূর্ণ সমস্যা অলক্ষিত থেকে যাবে। অভ্যন্তরীণ বিজ্ঞপ্তিতে অর্ডার নম্বর, পরিষেবা, বর্তমান স্ট্যাটাস, বাহ্যিক ID এবং কার্ডের লিঙ্ক থাকা উচিত।

লগ রাখুন এবং অসম্পূর্ণ অর্ডার মিলিয়ে দেখুন

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

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

পর্যায়ক্রমে API ডেটা পাওয়ার পদ্ধতির মাধ্যমে মধ্যবর্তী স্ট্যাটাসে থাকা অর্ডার মিলিয়ে দেখুন। এই যাচাই ওয়েবহুক প্রতিস্থাপন করে না, তবে মিস হওয়া ইভেন্ট, সারি ব্যর্থতা বা এমন ক্ষেত্রে সনাক্ত করতে সাহায্য করে যখন বাহ্যিক স্ট্যাটাস সঠিক বিজ্ঞপ্তি ছাড়াই পরিবর্তিত হয়েছে।