სიახლეები და ანალიზი
გადახდების შეჯერება: მცდელობების, გაუქმებებისა და ჩანაწერების დაკავშირება
Payment Intent-ის, Payment Record-ისა და მცდელობების დაკავშირება, Stripe-ის გაუქმების ანგარიშების სწორად გაგება და შეუსაბამობების სამუშაო რიგი.
სააღრიცხვო სისტემა შეკვეთას გადახდილად აღნიშნავს, მომწოდებელი წარუმატებელ მცდელობას აჩვენებს, მხარდაჭერა კი გაუქმებას აღწერს. სამივე ჩანაწერი შეიძლება ერთ შეკვეთას ეხებოდეს, მაგრამ სხვადასხვა მოვლენას ასახავდეს. შეჯერება ამ ცნებების გამიჯვნით იწყება: გადახდის განზრახვა, ცალკეული მცდელობა, შეტყობინებული შედეგი და ფულის რეალური მოძრაობა.
Stripe API-ის 2026-09-30.endive ვერსია Payment Records-ის ცვლილებებს შეიცავს, რომლებიც კავშირებისა და მდგომარეობების უფრო ზუსტ აღწერას ეხმარება. ეს დამატებითი მონაცემებია ინტეგრაციისთვის და არა ფინანსური აღრიცხვის წესების შემცვლელი. სასარგებლო განახლება შეუსაბამობებს ახსნადს და დაკავშირებულ ჩანაწერებს მოსაძებნს ხდის; იგი ავტომატურ შეჯერებას არ ადასტურებს.
Payment Intent მის Payment Record-ს დაუკავშირეთ
Stripe-ის payment_record ცვლილებების ჟურნალი Payment Intent-ზე ახალ გასაშლელ თვისებას აღწერს. ის შესაბამისი Payment Record-ის იდენტიფიკატორს შეიცავს. Stripe-ის თანახმად, Payment Records-ის მომხმარებელ ინტეგრაციას დაკავშირებული ჩანაწერის მიღება პირდაპირ Payment Intent-იდან შეუძლია, კავშირის ცალკე ძიების გარეშე.
ეს შესაძლებლობა პირობითია და Payment Records-ის მომხმარებელ ინტეგრაციებს ეხება. იგი არ ნიშნავს, რომ მაღაზიის ყველა შეკვეთას სრული სააღრიცხვო ჩანაწერი აქვს ან კავშირი თანხას ავტომატურად ამოწმებს. აპლიკაციას კვლავ სჭირდება შიდა შეკვეთის იდენტიფიკატორები, მომწოდებელთან კავშირები და დაკარგული მონაცემების წესები.
ჯერ რუკა შექმენით: შიდა შეკვეთა, Payment Intent, Payment Record და საჭიროებისას ცალკეული მცდელობები. შეინარჩუნეთ ობიექტების იდენტიფიკატორები; ნუ შეადარებთ ჩანაწერებს მხოლოდ ელფოსტით, მსგავსი თანხით ან ახლო დროით. ასეთი ნიშნები გამოკვლევას ამართლებს, მაგრამ ავტომატური გაერთიანებისთვის საკმარისი არ არის.
გაუქმება ანგარიშში ასახვადი შედეგი ხდება
გაუქმებული გადახდების აღწერაში Stripe გადახდის ან მცდელობის შეტყობინების outcome ველს canceled მნიშვნელობას ამატებს. მანამდე ჩამოთვლილი იყო guaranteed და failed. outcome: canceled მოითხოვს canceled პარამეტრს, რომელიც canceled_at დროის ნიშნულს შეიცავს.
Stripe აღწერს გაუქმებული გადახდის Payment Record-ის ერთი გამოძახებით შექმნას. არსებული ჩანაწერისთვის ინტეგრაციას გაუქმებული მცდელობის შეტყობინება წინა ორშეტყობინებიანი მიმდევრობის გარეშე შეუძლია. იცვლება შედეგის ჩაწერის გზა. ეს არ ნიშნავს, რომ ანგარიშის გაგზავნა თავისთავად გადახდის ოპერაციას აუქმებს ან თანხას აბრუნებს.
ამიტომ შიდა „გაუქმებულ“ სტატუსს ზუსტი განსაზღვრება სჭირდება. გაუქმებული შეკვეთა, გადახდის გაუქმებული მცდელობა და დასრულებული დაბრუნება სხვადასხვა მდგომარეობაა. თუ აპლიკაცია ყველას ერთ ველში ინახავს, ახალი API შესაძლებლობა მხოლოდ დამატებით მნიშვნელობას დაუმატებს უკვე ბუნდოვან მოდელს.
შეამოწმეთ wallet.type-ის მომხმარებლები
მესამე განახლება ეხება Link საფულის დეტალებს Payment Records-სა და Payment Attempt Records-ზე. Stripe Link ბარათით გადახდებისთვის ამატებს link ტიპსა და ობიექტს არჩევითი, null-ის დასაშვები funding_source_group ველით. წყარო იდენტიფიკატორს გაუმჭვირვალედ და უცვლელად აღწერს; იგი დადასტურებისას განისაზღვრება.
ინტეგრაციამ, რომელიც wallet.type-ის ყველა მნიშვნელობას ცალ-ცალკე ამუშავებს, ახალი მნიშვნელობაც უნდა გაითვალისწინოს. დაკარგული funding_source_group ავტომატურად გადახდის შეცდომად არ უნდა იქცეს: ველი შეიძლება null იყოს. იდენტიფიკატორს ნუ მიაწერთ ბანკის, მომხმარებლის ან საბუღალტრო ანგარიშის მნიშვნელობას; განცხადება ასეთ განმარტებას არ იძლევა.
შეჯერებისთვის მნიშვნელოვანია, რომ პარსერმა საფულის ახალი აღწერის გამოჩენისას ჩანაწერი არ გადააგდოს. დაფინანსების წყაროს ჯგუფის დამთხვევა გადახდის იდენტიფიკატორს არ ცვლის და არ ამტკიცებს, რომ ორი ოპერაცია ერთ შეკვეთას ეკუთვნის.
ერთნაირი მნიშვნელობის ჩანაწერები შეადარეთ
წარმოიდგინეთ გამოწერა, რომლის კლიენტი ორჯერ ცდილობს გადახდას: პირველი მცდელობა მარცხდება, მეორეს კი დადასტურებული შედეგი აქვს. ეს საილუსტრაციო სცენარია. სისტემამ ორივე მცდელობა უნდა შეინარჩუნოს და ცალკე მიუთითოს ვალდებულების შესრულებულად მიჩნევის საფუძველი.
თითოეული შესაჯერებელი ოპერაციისთვის შეინახეთ იდენტიფიკატორები, თანხა, ვალუტა, მოვლენის დრო, მიღების დრო და მკაფიო მდგომარეობა. თანხები შეთანხმებულ ერთეულებში შეადარეთ, დროის ერთიანი წესი გამოიყენეთ და უცნობი შედეგები საკმარის მტკიცებულებამდე შეინარჩუნეთ. აღრიცხვაზე პასუხისმგებელთან შეათანხმეთ საბოლოო ფულადი მდგომარეობის განმსაზღვრელი წყარო.
შედარების საზღვარიც მნიშვნელოვანია. გადახდის ოპერაციული შედეგი, მომწოდებლის ანგარიშსწორება, საკომისიო და საბუღალტრო გატარება შეიძლება სხვადასხვა დროს ჩაიწეროს. ახალი Payment Records ველები ამ თანხებს ერთმანეთის ტოლს არ ხდის. შეადარეთ ეკვივალენტური ობიექტები და ახსენით დროის მოსალოდნელი განსხვავებები.
შეუსაბამობა შესასრულებელ ამოცანად აქციეთ
ანგარიში წარწერით „არ ემთხვევა“ საკმარისი არ არის. გამოყავით მიზეზები: დაკარგული კავშირი, უცნობი მდგომარეობა, თანხის სხვაობა, დაგვიანებული მოვლენა ან გადასახედი ფინანსური ოპერაცია. თითოეულს პასუხისმგებელი და უსაფრთხო შემდეგი მოქმედება სჭირდება.
დაკარგული ჩანაწერისას შეკვეთას გადახდილად ნუ მონიშნავთ მხოლოდ ანგარიშის გასასუფთავებლად. გაუქმების შეტყობინებისას ჯერ გაარკვიეთ, რა გაუქმდა და არსებობს თუ არა ფულის ცალკე მოძრაობა. ხელახალი შემოწმებისთვის საწყისი იდენტიფიკატორები და წინა გადაწყვეტილება შეინახეთ. ასე ისტორია მხარდაჭერისა და ფინანსების თანამშრომლებისთვის გასაგები რჩება.
პროცესი შეიძლება გახდეს შიდა ბიზნესსისტემის ნაწილი, რომელიც პასუხისმგებელსა და შემდეგ ამოცანას აჩვენებს. API ინტეგრაციებით გადაცემას მდგომარეობების მკაფიო კონტრაქტები სჭირდება. ინდივიდუალური API-ის არქიტექტურის აღწერა მოდელებისა და საერთო რესურსების კონტექსტს იძლევა, მაგრამ იმ პროექტში Payment Records-ის გამოყენებას არ ადასტურებს.
გამოშვებამდე მნიშვნელობა გადაამოწმეთ
განახლებისას შეამოწმეთ ახალი კავშირი, გაუქმებული შედეგი დროის ნიშნულით, link მნიშვნელობა და null-ის დასაშვები ველი. შემდეგ გაიარეთ ბიზნესსცენარები: ორი მცდელობა ერთ შეკვეთაზე, დაკარგული ჩანაწერი, დაგვიანებული შეტყობინება და გაუქმება დაბრუნების გარეშე. მიზანია ტექნიკური მოვლენა ფინანსურ დასტურად არ იქცეს.
გამოწერის პროდუქტებისთვის გამოწერის გაუქმების პროცესიც შეისწავლეთ. მომავალი ჩამოჭრების შეჩერებასა და წარსული გადახდის შედეგის დადგენას სხვადასხვა წესი სჭირდება. მაღაზიამ იგივე განსხვავება შეკვეთების ცვლილებებსა და დაბრუნებებში უნდა შეინარჩუნოს.
დაიწყეთ შეუსაბამობების მცირე რიგით, რომლის გამოკვლევაც გუნდს რეალურად შეუძლია. გაზომეთ მოუგვარებელი შემთხვევების ასაკი, კავშირების სისრულე და ხელით შესწორებების მიზეზები. ეს შემდგომ ავტომატიზაციას საფუძველს მისცემს ისე, რომ გაურკვევლობა ერთი მწვანე სტატუსის უკან არ დაიმალოს.