BillingMeld: কেন কেনাকাটা সার্ভার দ্বারা নিশ্চিত করা উচিত, অ্যাপ নয়

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

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

মূল সমস্যা দেখা দেয় যখন সার্ভার ক্লায়েন্ট অ্যাপকে সত্যের উৎস হিসেবে গণনা শুরু করে।

যখন অ্যাপ বলছে: “ক্রয় সম্পন্ন,” তখন সার্ভার অ্যালাউ করে এবং একবার যে অবস্থা গ্রহণ করেছে তার ওপর ভিত্তি করে চলতে থাকে। কিন্তু কেনাকাটার জীবনচক্র এখানেই শেষ হয় না।

সাবস্ক্রিপশন নবীন হতে পারে, স্বয়ংক্রিয় নবীনকরণ বন্ধ হতে পারে, টাকা ফেরত দিতে পারে, বা অপারেশন স্টোর দ্বারা প্রত্যাহার করা যেতে পারে।

এই কারণেই BillingMeld-এ কেনাকাটা সার্ভার দ্বারা নিশ্চিত করা হয়, অ্যাপ নয়।

ক্লায়েন্ট জানাচ্ছে, কিন্তু সিদ্ধান্ত নিচ্ছে না

BillingMeld-এর আর্কিটেকচারে মোবাইল অ্যাপ কি কেনাকাটার মূল উৎস নয়।

ক্লায়েন্ট ক্যার থেকে ডেটা পাঠাতে পারে, কিন্তু এটি শুধুমাত্র পরীক্ষা করার জন্য ভিত্তি। চূড়ান্ত সিদ্ধান্ত নেয় সার্ভার অংশ, যা Apple বা Google-এর অবকাঠামোর মাধ্যমে তথ্য যাচাই করে।

এটা অন্যতম মূল পার্থক্য।

স্মার্টফোনে অ্যাপ পুরানো অবস্থার সঙ্গে কাজ করতে পারে, সময়মতো সংশোধনী পায় না বা এমন তথ্য পাঠাতে পারে যা এখন আর প্রাসঙ্গিক নয়।

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

BillingMeld পরীক্ষা করে, যেমন:

• অবশ্যই ওই ধরনের কেনাকাটা রয়েছে কি না;

• এটি কি নির্দিষ্ট অ্যাপ ও পণ্য সম্পর্কিত;

• পরিশোধিত সময় বর্তমানে প্রযোজ্য কি না;

• নবীনকরণ হয়েছে কি না;

• অটোমেটিক নবীনকরণ বন্ধ করা হয়েছে কি না;

• রিফান্ড হয়েছে কি না;

• অপারেশন প্রত্যাহার হয়েছে কি না;

• পরিশোধিত সময় শেষ হয়েছে কি না।

অর্থাৎ, ক্লায়েন্টের বার্তা হল কেবল কেনাকাটার প্রমাণ নয়, এটি এর প্রকৃত অবস্থা যাচাই করার কারণ।

সার্ভার জন্য একক সত্যের উৎস

অভিনব পরিষেবাগুলিকে একসঙ্গে Apple ও Google-র সঙ্গে পূর্ণ ইন্টিগ্রেশন বাস্তবায়নের প্রয়োজন হয় না।

তারা BillingMeld-এ জিজ্ঞাসা করে এবং তারা ইতিমধ্যে স্বাভাবিককৃত কেনাকাটার অবস্থা পায়।

উদাহরণস্বরূপ: অ্যাক্সেস সক্রিয়, পরিশোধকৃত সময় শেষ, নবীনকরণ নিশ্চিত, অটোমেটিক নবীনকরণ বন্ধ, বা কেনাকাটা প্রত্যাহার।

এটি দায়িত্ব ভাগ করে নেওয়া সহজ করে।

Apple এবং Google হল কেনাকাটার অবস্থা সূত্র। BillingMeld এই তথ্য যাচাই করে, একত্রিত করে এবং বর্তমান অবস্থা সংরক্ষণ করে। এবং চূড়ান্ত সিদ্ধান্ত অ্যাক্সেসের জন্য তার অবস্থা দেখে নেওয়া হয়।

প্রোডাক্ট সার্ভারদের জন্য, এটি একটি একক চুক্তি নির্দেশ করে, যেখানে একাধিক স্বাধীন ইন্টিগ্রেশন প্রয়োজন হয় না।

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

কেন ক্লায়েন্টকে পুরোপুরি বিশ্বাস করা উচিত নয়

ক্লায়েন্ট অ্যাপ ব্যবহারকারীর ডিভাইসে কাজ করে।

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

কোনো ব্যবহারকারীর হস্তক্ষেপ ছাড়াই, এটি চূড়ান্ত অবস্থা সম্পর্কে খারাপ উৎস হিসেবে দাঁড়ায়।

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

অন্য পরিস্থিতিতে, ব্যবহারকারী অটোমেটিক নবীনকরণ বন্ধ করতে পারেন। তখন, ইতিমধ্যে পরিশোধিত সময় এখনও সক্রিয় থাকা উচিত।

যদি সিস্টেম শুধুমাত্ৰ স্বত্বের উপর ভিত্তি করে কাজ করে, যেমন “সাবস্ক্রিপশন আছে / না”, এটি সহজেই অপ্রয়োজনীয় বা ভূল তথ্য দিয়ে অ্যাক্সেস বন্ধ বা চালিয়ে রাখতে পারে।

BillingMeld আলাদা করে অন্য লজিকের উপর ভিত্তি করে গড়ে তোলা— ক্লায়েন্ট নিজের অধিকার নিশ্চিত করে না; এটি ঘটনা জানায়, এবং সার্ভার প্রকৃত অবস্থা নিরূপণ করে।

ক্রয় — এটা একক ঘটনা নয়

বিলিং আর্কিটেকচারে মূল ভুল একটিই — কেনাকাটাকে একক ঘটনা হিসেবে দেখা।

এর জীবনচক্র রয়েছে।

প্রথমে অপারেশন তৈরি হয়। তার পরে এটি স্টোর দ্বারা নিশ্চিত হয়। সাবস্ক্রিপশনের জন্য শুরু হয় সম্পূর্ণ পেমেন্টের সময়। পরবর্তীতে নবীনকরণ হতে পারে।

ব্যবহারকারী অটোমেটিক নবীনকরণ বন্ধ করতে পারেন, কিন্তু একই সময়ে, সাবস্ক্রিপশন ব্যবহৃত হওয়া অবধি থাকে।

পরের নবীনকরণের জন্য পেমেন্ট ব্যর্থ হতে পারে।

ফিরতিও হতে পারে।

কিছু ক্ষেত্রে, কেনাকাটা প্রত্যাহার করা যেতে পারে।

অর্থাৎ, “কখনো এই কেনাকাটা ছিল” এই তথ্য পর্যাপ্ত নয়।

সার্ভার বুঝতে হবে যে, এখন কি অবস্থা।

প্রতিবেদন না থাকলে অবস্থা অপ্রত্যাশিত নয়

ফিরত ও প্রত্যাহার অপারেশনে সার্ভার আर्कিটেকচারের প্রয়োজনীয়তা স্পষ্ট হয়।

প্রাথমিক কেনাকাটা সম্পূর্ণ ঠিকঠাক ছিল। ব্যবহারকারী প্রকৃতপক্ষে পণ্য পরিশোধ করেছে এবং অ্যাক্সেস পেয়েছে।

কিন্তু পরে, অপারেশনের অবস্থা পরিবর্তিত হয়েছে।

BillingMeld পরিবর্তন সংবাদের তথ্য পেলে, এটি নিজের অবস্থা আপডেট করে এবং প্রয়োজন হলে, স্টোরের মাধ্যমে অতিরিক্ত যাচাই করে।

এরপর, সংযুক্ত পরিষেবা নতুন স্ট্যাটাসের সঙ্গে কাজ করে।

অর্থাৎ, অ্যাপ্লিকেশন কখনোই শেষ বা শেষ নয় যে কিছু সপ্তাহ বা মাস আগে ক্লায়েন্ট সফল কেনাকাটা জানিয়েছিল।

যদি স্টোর সেই অধিকারটি আর কার্যকর মনে না করে, BillingMeld তা নিজের অবস্থা refleেক করে।

সাবস্ক্রিপশন বাতিল এবং অ্যাক্সেস শেষ—একই নয়

এখানে একটি গুরুত্বপূর্ণ পার্থক্য রয়েছে।

যদি ব্যবহারকারী অটোমেটিক নবীনকরণ বন্ধ করে, সাধারণত তার মানে নয় যে ডিভাইসের অ্যাক্সেস এখনো বন্ধ হয়ে যাবে।

বর্তমান পরিশোধিত সময় চলমান থাকবে।

এক্ষেত্রে, BillingMeld চালিয়ে যাওয়ার জন্য তথ্য রাখে যে, নবীনকরণ বন্ধ করা হয়েছে, কিন্তু একই সময়ে, ইতিমধ্যে পরিশোধিত সময়ের তারিখটি জানে।

শুধুও, এর শেষ হওয়ার পরে অ্যাক্সেস আর সক্রিয় বলে গণনা হয় না, যদি নতুন নিশ্চিতকরণ হয় না।

এটি এমন একটি উদাহরণ যেখানে সহজ “subscription = true” মান পর্যাপ্ত নয়।

সাবস্ক্রিপশনের অবস্থা সবসময় সময় ও এর জীবনচক্রের ঘটনাগুলির সঙ্গে সম্পর্কিত।

নবীনকরণও একটি পৃথক পরীক্ষার বিষয়

সাবস্ক্রিপশন প্রথম পরিশোধে শেষ হয় না।

সার্ভার বুঝতে হবে, কি নবীনকরণ হয়েছে এবং কি নাকি পরবর্তী সময়ের জন্য সত্যিই নিশ্চিতকরণ পাওয়া গেছে।

BillingMeld এসব পরিবর্তন ট্র্যাক করে এবং অবস্থা আপডেট করে।

যদি নবীনকরণ নিশ্চিত হয়, তবে অ্যাক্সেসের অধিকার চলমান থাকে।

যদি পুনরায় অর্থপ্রদান না হয় বা স্টোর পরবর্তী পদক্ষেপের জন্য নিশ্চিত না হয়, সিস্টেম কেবল অনুমান করে না – থাকা অবস্থা ধরে রাখে।

ব্যবহারকারীর জন্য, এটা স্বাভাবিক মনে হয়: যতক্ষণ নিশ্চিত কেনাকাটা চলমান থাকে, ততক্ষণই অ্যাক্সেস।

উন্নয়কদের জন্য, অর্থাৎ, তারা আরেকটি নবীনকরণ লজিক পুনরায় বাস্তবায়ন করতে হবে না।

সাধারণ চিত্র কীভাবে দেখা যায়

ব্যবহারকারী মোবাইল অ্যাপে সাবস্ক্রিপশন নেয়।

ক্লায়েন্ট কেনাকাটার তথ্য পায় এবং তা BillingMeld-এ পাঠায়। তবে এই বার্তা এখনও কেনাকাটার চূড়ান্ত নিশ্চিতকরণ নয়।

BillingMeld সংশ্লিষ্ট স্টোরের মাধ্যমে অপারেশন পরীক্ষ করে।

যদি অ্যাপ স্টোর বা Google Play কেনাকাটা নিশ্চিত করে এবং অবস্থা পণ্য নিয়ম অনুযায়ী হয়, BillingMeld সক্রিয় অধিকার রেকর্ড করে।

এরপর সংযুক্ত পরিষেবা ব্যবহারকারীর জন্য অর্থপ্রাপ্ত সুবিধা প্রদান করে।

অবস্থা এরপর নিজে থেকে স্বতঃস্ফূর্তভাবে পরিবর্তিত হয়নি।

যদি সাবস্ক্রিপশন নবীন হয়, BillingMeld নতুন পরিশোধিত সময় মনে করে।

যদি ব্যবহারকারী অটোমেটিক নবীনকরণ বন্ধ করে, বর্তমান সময় অবধি থাকে।

অপারেশন ফেরত বা প্রত্যাহার হলে, অবস্থা ফের পরিবর্তিত হয়।

এই ধাঁচে, অ্যাপ্লিকেশন কেনাকাটার নিজস্ব “সত্য” সংরক্ষণ করে না। এটি সেই অবস্থা নিয়ে কাজ করে, যা নিশ্চিত ও সংরক্ষিত হয়েছে BillingMeld দ্বারা।

যখন ডিভাইস পরিবর্তন হয় তখন কী হয়

সার্ভার ভিত্তিক ধারণা বিশেষভাবে কার্যকর যখন একজন ব্যবহারকারী ফোন পরিবর্তন করে বা অ্যাপ আবার ইনস্টল করে।

অধিকার শুধুমাত্র অ্যাপের একটি সফল লেনদেন দেখা দ্বারা অস্তিত্ব বজায় রাখে না।

এবং উল্টো, অ্যাপের পুনরায় ইনস্টল ব্যবহারকারীর নিশ্চিত অধিকার মুছে ফেলবে না।

যদি কেনাকাটার অবস্থা সার্ভারে থাকে এবং নিশ্চিত স্টোর অপারেশনের সঙ্গে যুক্ত থাক, তাহলে নতুন ডিভাইস সার্ভার থেকে আপডেটেড অবস্থা পেতে পারে।

এটাই আরেক কারণ যে, অ্যাক্সেসের লজিক শুধুমাত্র মোবাইল ক্লায়েন্টের মধ্যে রাখা উচিত নয়।

এটি ডেভেলপারদের জন্য কী দেয়

একাধিক মোবাইল অ্যাপ বা আইওএস ও অ্যান্ড্রয়েড-সহ কাজ করা দলের জন্য, বিলিং খুব দ্রুত একটি স্বতন্ত্র অবকাঠামো সমাধানে পরিণত হয়।

তাদের লক্ষ্য রাখতে হবে:

• অ্যাপল ও গুগল-এর ডেটার আলাদা ফরম্যাট;

• প্রাথমিক কেনাকাটার নিশ্চিতকরণ;

• নবীনকরণ;

• পরিশোধের শেষের সময়;

• অটোমেটিক নবীনকরণ বন্ধ;

• ফেরত;

• অপারেশন প্রত্যাহার;

• অ্যাপ পুনঃইন্সটল;

• ডিভাইস পরিবর্তন;

• কেনাকাটার পুনরুদ্ধার;

• অবস্থা পরিবর্তন যা ক্লায়েন্টের অংশগ্রহণ ছাড়াই হয়েছে।

BillingMeld এসব লজিককে একটি বিশেষায়িত স্তরে স্থানান্তর করে।

প্রোডাক্ট সার্ভাররা এর সঙ্গে একটি একক চুক্তিতে কাজ করে এবং প্রতিটি স্টোরের আলাদা বৈশিষ্ট্যগুলি নিজে থেকে বিবেচনা করে না।

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

চেক নয়, সত্যের আধারই গুরুত্বপূর্ণ

এই আর্কিটেকচারে আমার সবচেয়ে বেশি আগ্রহের বিষয় হচ্ছে, সংশ্লিষ্ট কেনাকাটার চেক থেকে এখন মূল সত্যের যাচাইয়ে পরিবর্তন।

অর্থপ্রদান ইতিহাস নিজে কোনও বড় প্রশ্নের উত্তর না দিয়ে, মূল প্রশ্নের উত্তরে সাধারণত যথেষ্ট নয়:

ব্যবহারকারীর এখন কি পেইড ফিচার পাওয়ার অধিকার আছে?

অর্থপ্রদানটি হয়তো প্রথমে সফল ছিল, তবে তার পূর্ণ সময় শেষ।

সাবস্ক্রিপশনে হয়তো অটোমেটিক নবীনকরণ বন্ধ, কিন্তু ইতিমধ্যে পেমেন্ট হওয়া সময় এখনও সক্রিয়।

নবীনকরণ নিশ্চিত হয়েছে কি না;

ফেরত হয়েছে কি না;

স্টোর অপারেশন প্রত্যাহার করেছে কি না।

অর্থাৎ, মূল অবজেক্ট ক্রয় এবং প্রাথমিক ক্লায়েন্ট উত্তর নয়, বরং নিশ্চিত অবস্থা ভিত্তিক ব্যবহারকারীর প্রকৃত অধিকার।

এটাই এমন অবস্থা যা BillingMeld অন্য পরিষেবাগুলোর কাছে স্থানান্তর করে।

BillingMeld এর দোকান থেকে প্রোডাক্টের সীমা

ফলস্বরূপ, একটি স্পষ্ট আর্কিটেকচারাল সীমারেখা তৈরি হয়।

একপাশে রয়েছে অ্যাপ স্টোর ও গুগল প্লে, তাঁদের নিজেদের ফরম্যাট, ইভেন্ট, নিয়ম ও জীবনচক্র।

অন্যপাশে থাকেন অ্যাপ্লিকেশন ও অভ্যন্তরীণ পরিষেবাগুলি, যাদের অধিকাংশের জন্য প্রয়োজন আরও সরল উত্তর: এখন ব্যবহারকারীর অধিকার কী।

এমধ্যে রয়েছে BillingMeld।

সে দোকানের ডেটা গ্রহণ করে, যাচাই করে, নিজের মডেলে রূপান্তর করে এবং অন্যান্য অবকাঠামোকে স্বাভাবিক ফলাফল সরবরাহ করে।

এতে সুবিধা হয় যে, প্রোডাক্টগুলো প্রত্যেক স্টোরের অভ্যন্তরীণ বৈশিষ্ট্যগুলো জানার প্রয়োজন হয় না।

এটি ব্যবহারকারীর জন্য কেন গুরুত্বপূর্ণ

ব্যবহারকারীর জন্য সঠিক বিলিং আর্কিটেকচার মূলত স্বাভাবিকভাবে অপরিচিত থাকাই উত্তম।

যদি কেনাকাটা নিশ্চিত হয় এবং পেমেন্টের সময় চালু থাকে, তাহলে অ্যাক্সেস স্বাভাবিক থাকা উচিত।

যদি ব্যবহারকারী অটোমেটিক নবীনকরণ বন্ধ করে, তখন ইতিমধ্যে পরিশোধিত সময় পূর্বে শেষ হওয়া উচিত নয়।

নবীনকরণ নিশ্চিত হলে, অ্যাক্সেস চালিয়ে যেতে হবে।

যদি স্টোর ফেরত বা প্রত্যাহার করে, তখন সিস্টেম অবশ্যই পরিবর্তন প্রতিফলিত করতে হবে।

ডিভাইস পরিবর্তন বা অ্যাপ রি-ইনস্টলেশন হলে, ব্যবহারকারীকে পুনরায় প্রমাণ দিতে হবে না যে কেনাকাটা প্রকৃতপক্ষে অস্তিত্বে আছে।

একটি সহজ নিয়ম এই রকম:

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

এটাই কারণ যে, BillingMeld শুধুমাত্র একাধিক পেমেন্ট মডিউলের চেয়েও বেশি — এটি মোবাইল অ্যাপ, অ্যাপেল ও গুগল দোকান ও প্রোডাক্টের মধ্যে আস্থার সার্ভার স্তর।

আরও বিস্তারিত: billingmeld.de.