მობილურ აპში გადახდის ინტეგრაცია: რა შეიძინოთ
გადახდის ინტეგრაციის დაკვეთის ჩარჩო: გადახდის ტიპი, სტატუსები, დაბრუნება, უსაფრთხოება, store policy და მიღების მტკიცებულება.
გადახდის ინტეგრაციის შეკვეთაში მიუთითეთ, რას ყიდულობს მომხმარებელი, ვის ანგარიშზე შედის თანხა და როგორ მუშავდება უარი, დაბრუნება და განმეორებითი მოთხოვნა. ბარათის ფორმა გადახდის მთელი გზა არ არის.
გადახდის სცენარების წინასწარი განხილვა შეგიძლიათ aiAPP-ის საკონტაქტო ფორმით დაიწყოთ, როცა უკვე ჩამოწერილი გაქვთ თანხის მოძრაობა და გამონაკლისები.
გადახდის ტიპის განსაზღვრა
პირველი განსხვავებაა ციფრულ შიგთავსსა და ფიზიკურ ან რეალურ მომსახურებას შორის. აპის შიგნით ციფრული ფუნქციის ან შიგთავსის გაყიდვას შეიძლება მაღაზიის billing წესები შეეხოს. ფიზიკური პროდუქტის, ადგილზე მომსახურების, მიწოდების ან ჯავშნის გადახდა სხვა გზით იმართება. ეს სტატია იურიდიულ დასკვნას არ იძლევა, მაგრამ შესყიდვის დოკუმენტში პროდუქტის ტიპი აუცილებლად უნდა ეწეროს.
შემდეგ გამოყავით ერთჯერადი ბარათის გადახდა, გამოწერა, წინასწარი ავტორიზაცია, განვადება, დეპოზიტი და დაბრუნება. თითოეულს სხვადასხვა სტატუსი და ოპერაციული პასუხისმგებლობა აქვს. თუ შეთავაზება მხოლოდ „payment gateway integration“-ს ამბობს, ვერ გაიგებთ, უკავშირდება თუ არა იგი თქვენი რეალური ბიზნესის ფულადი მოძრაობის წესს.
Apple Pay-ის დოკუმენტაცია გადახდის მომწოდებლის SDK-ს ან API-ს გამოყენებას აღწერს. Quickpay-ის API დოკუმენტაციაში ჩანს, რომ გადახდის ნაკადი შეიძლება მოიცავდეს payment URL-ს, ბანკის დადასტურებას და payment.paid webhook-ს. ეს წყაროები აჩვენებს მექანიზმების მაგალითებს და არ ადასტურებს, რომ რომელიმე კონკრეტული გზა თქვენს ქვეყანაში ან პროდუქტში ავტომატურად გამოდგება.
გადახდის ნაკადის რუკა
გადახდის გზას დაურთეთ სამი მონაწილე: მყიდველი, თქვენი ბიზნესი და გადახდის მომწოდებელი. შემდეგ ჩაწერეთ მოქმედებები: შეკვეთის შექმნა, გადახდის დაწყება, ბანკის გვერდზე გადასვლა, პასუხის მიღება, webhook-ის დამუშავება, სტატუსის განახლება და მომხმარებლისთვის დადასტურების ჩვენება. აპმა მხოლოდ დაბრუნებულ ეკრანს არ უნდა ენდოს, თუ საბოლოო სტატუსს სერვერი ადგენს.
- პირველი მოთხოვნა: როგორ იქმნება უნიკალური შეკვეთა და როგორ იბლოკება დუბლირება?
- გადახდის გვერდი: სად შეჰყავს მომხმარებელს ბარათის მონაცემები და ვის ეკუთვნის ეს გარემო?
- დადასტურება: რომელი პასუხი აქცევს შეკვეთას გადახდილად?
- დაბრუნება: როგორ გადაეცემა თანხის დაბრუნება, თანხის ნაწილობრივი დაბრუნება ან გაუქმება აპსა და ანგარიშში?
- შეცდომა: რას ხედავს ადამიანი, როცა ფული ჩამოიჭრა, მაგრამ აპმა პასუხი ვერ მიიღო?
ეს ნაბიჯები ცალკე მდგომარეობებად ჩაწერეთ. „წარმატება“ და „pending“ ერთსა და იმავეს არ ნიშნავს. თუ ბანკის პასუხი დაგვიანდა, აპმა მომხმარებელს ხელახლა გადახდა არ უნდა მოსთხოვოს, სანამ პირველი მცდელობის შედეგი არ გაირკვევა.
აპის გადახდა და მაღაზიის ბილინგი
| სიტუაცია | მთავარი შემოწმება | დაკვეთაში ჩასაწერი პასუხისმგებელი |
|---|---|---|
| ფიზიკური პროდუქტი ან ადგილზე სერვისი | ბანკი/PSP, შეკვეთა, დაბრუნება და მიწოდება | მერჩანტის ანგარიშის მფლობელი |
| ციფრული ფუნქცია ან შიგთავსი | App Store და Google Play billing policy | store policy-ის მიმომხილველი |
| გამოწერა | განახლება, გაუქმება, დადასტურება და ანგარიშგება | ფინანსური და ტექნიკური მფლობელი |
| Marketplace | მყიდველის თანხა, საკომისიო, seller payout და dispute | ოპერატორი და გადახდის მომწოდებელი |
ამ განსხვავების გამოტოვებით მყიდველმა შეიძლება შეადაროს ორი შეთავაზება, რომელთაგან ერთი მხოლოდ ბარათის ფორმას აკეთებს, მეორე კი სტატუსებს, დაბრუნებასა და ანგარიშგებას. ერთი სახელის ქვეშ სხვადასხვა სამუშაოა.
რა ტექნიკური მტკიცებულება მოითხოვოთ?
მიღების ტესტში ჩართეთ წარმატებული გადახდა, უარი, გაუქმება, კავშირის გაწყვეტა, განმეორებითი შეხება, დაგვიანებული webhook, თანხის დაბრუნება და აპის ხელახლა გახსნა. თითოეულ სცენარს ჰქონდეს წინასწარ განსაზღვრული მდგომარეობა. სატესტო ბარათები და sandbox გარემო უნდა ჰქონდეს პასუხისმგებელ provider-ს ან ფინანსურ მფლობელს.
სთხოვეთ ჟურნალში გამოჩნდეს საკმარისი იდენტიფიკატორი, რომ ოპერატორმა შეკვეთა იპოვოს, მაგრამ ბარათის სრული მონაცემი არ შეინახოს. ჩაწერეთ ვინ მართავს საიდუმლოებებს, როგორ იცვლება API key, ვინ იღებს webhook-ის შეცდომას და როგორ ხდება ოპერაციების შეჯერება. უსაფრთხოების გვერდი aiAPP-ის საიტზე პროდუქტის საერთო საზღვრებს აღწერს, ხოლო კონკრეტული გადახდის რისკი პროექტში უნდა დაიშალოს.
როგორ შეადაროთ გადახდის მომწოდებლის შეთავაზებები?
შეადარეთ არა ლოგოების სია, არამედ ხელმისაწვდომი პროცესი, ანგარიშის პირობები, ქვეყნები, ვალუტა, თანხის დაბრუნება, webhook, sandbox, მხარდაჭერა და მონაცემთა პასუხისმგებლობა. Quickpay-ის გვერდი სხვადასხვა gateway slug-სა და webhook-ს აღწერს. Integral-ის გვერდი Bank of Georgia-ს ონლაინ გადახდის ინტეგრაციას ასახელებს. ეს კომერციული შეთავაზებები კვლევის წყაროა; საბოლოო ხელმისაწვდომობა და კონტრაქტი უშუალოდ მომწოდებელთან უნდა გადამოწმდეს.
მომწოდებელს ჰკითხეთ, გადახდის მომწოდებლის კონტრაქტს თქვენ აფორმებთ თუ ის მართავს თქვენს ანგარიშს. სასურველია ბიზნესმა იცოდეს, სად ინახება წვდომის მონაცემები, ვის ეკუთვნის მართვის პანელი და როგორ გადაეცემა წვდომა. aiAPP-ის პროექტში კონკრეტული მომწოდებელი, ბანკი და გადახდის მეთოდი წინასწარ დაპირებული არ არის.
რა ჩაწეროთ payment integration brief-ში?
- დაასახელეთ პროდუქტის ტიპი და გაყიდვის ქვეყნები.
- დახაზეთ თანხის მოძრაობა მომხმარებლიდან ბიზნესამდე.
- ჩამოწერეთ გადახდის, pending, უარის და თანხის დაბრუნების სტატუსები.
- მიუთითეთ მომწოდებლის ანგარიში, მფლობელი და sandbox წვდომა.
- ჩაწერეთ webhook, დუბლირების, timeout-ის და დაბრუნების ტესტები.
- დაამატეთ მომხმარებლისთვის გასაგები შეტყობინება ყველა შედეგზე.
- განსაზღვრეთ უსაფრთხოების, კონფიდენციალურობის და store policy-ის მიმომხილველი.
დოკუმენტი გაუგზავნეთ aiAPP-ის წერილობით განხილვას. საერთო მოთხოვნებისთვის გამოიყენეთ მოთხოვნების ჩეკლისტი, ხოლო დეველოპერის კითხვებისთვის შერჩევის კრიტერიუმები. კომერციული სამუშაო ფორმატი ცალკე გადაამოწმეთ.
რომელი შეცდომები ანგრევს გადახდის პროცესს?
შეცდომის ერთ-ერთი სცენარია, როცა აპი სერვერის დადასტურებამდე აჩვენებს „გადახდილია“. ცალკე შეამოწმეთ თანხის დაბრუნების გამოტოვება, ერთსა და იმავე შეკვეთაზე მეორე მოთხოვნა, sandbox-ის და live-ის არევა და გადახდის ანგარიშის შემსრულებლის ელფოსტაზე დატოვება. კიდევ ერთი შეცდომაა ციფრული პროდუქტისა და ფიზიკური მომსახურების store policy-ის ერთნაირად ჩათვლა.
მომწოდებლის ლამაზი checkout არ ამტკიცებს ოპერაციების შეჯერებას, მომხმარებლის დახმარებას ან საბოლოო ანგარიშგებას. მოითხოვეთ რთული სცენარის ჩვენება და ჩაწერეთ, ვინ იღებს გადაწყვეტილებას თითოეულ დავაზე.
რა შეზღუდვები უნდა იყოს კონტრაქტში?
გადახდის მომწოდებლის ხელმისაწვდომობა, ბანკის პირობები, თანხის დაბრუნების პროცესი, store review და რეგულაციური მოთხოვნები გარეთ არსებული დამოკიდებულებებია. aiAPP ვერ დაგპირდებათ კონკრეტულ ბანკს, საკომისიოს, approval-ს, გაყიდვებს ან ფულის დაბრუნების ვადას. ტექნიკური ინტეგრაციის დასრულება სავაჭრო ანგარიშის დამტკიცებას არ ნიშნავს.
გადახდის ფუნქცია მხოლოდ მაშინ ჩათვალეთ დასრულებულად, როცა თქვენი რეალური პროდუქტის გზა, სტატუსები, შეცდომები, დაბრუნება, ანგარიშის მფლობელობა და ტესტის მტკიცებულება წერილობით არის მიღებული.
ხშირად დასმული კითხვები
შეიძლება თუ არა Stripe ან სხვა provider ავტომატურად ავირჩიოთ?
ავტომატურად არა. არჩევანი დამოკიდებულია პროდუქტის ტიპზე, ქვეყანაზე, გადახდის წესზე, store policy-ზე, ხელმისაწვდომ ანგარიშზე და თანხის დაბრუნების პროცესზე.
საკმარისია წარმატებული გადახდის ტესტი?
არა. საჭიროა უარის, timeout-ის, განმეორებითი მცდელობის, დაგვიანებული webhook-ის, დაბრუნებისა და აპის ხელახლა გახსნის სცენარებიც.
ვის უნდა ეკუთვნოდეს გადახდის მართვის პანელი?
მფლობელობა წინასწარ ბიზნესმა უნდა განსაზღვროს. მომწოდებელს შეიძლება სამუშაო როლი მიეცეს, მაგრამ ანგარიშის კონტროლი და გადაცემის გზა წერილობით უნდა ჩანდეს.
დაკავშირებული მასალა
- მობილური აპის მოთხოვნების ჩეკლისტი
- დეველოპერის შერჩევის კრიტერიუმები
- გადახდის პროცესის განხილვა
- ინტეგრაციების გვერდი
- უსაფრთხოების საზღვრები
გამოყენებული წყაროები
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.