Haberler ve analiz
Ödeme mutabakatı: ödeme denemelerini, iptalleri ve kayıtları bağlamak
Payment Intent, Payment Record ve denemeleri eşleyin; Stripe iptal bildirimlerini yorumlayın ve işlem yapılabilir bir mutabakat kuyruğu yönetin.
Muhasebe sistemi siparişi ödenmiş gösterirken sağlayıcı başarısız bir deneme, destek ise iptal bildiriyor. Üç kayıt aynı siparişe ait olabilir, ancak farklı olayları anlatır. Ödeme mutabakatı bu varlıkları ayırarak başlar: ödeme niyeti, tek bir deneme, bildirilen sonuç ve gerçek para hareketi.
Stripe API'nin 2026-09-30.endive sürümü, bağlantı ve durumları daha kesin göstermek için Payment Records değişiklikleri getiriyor. Bunlar entegrasyona ek veri sağlar; finansal muhasebe kurallarının yerini almaz. Yararlı bir güncelleme, farkları açıklanabilir ve ilişkili kayıtları bulunabilir kılar; mutabakatın otomatikleştiğini göstermez.
Payment Intent'i kendi Payment Record'una bağlayın
Stripe payment_record değişiklik kaydı, Payment Intent üzerinde yeni bir genişletilebilir özellik açıklıyor. Bu özellik, ilişkili Payment Record'un kimliğini içerir. Stripe'a göre Payment Records kullanan entegrasyon, ayrı bağlantı sorgusu olmadan ilişkili kaydı doğrudan Payment Intent nesnesinden alabilir.
Bu, Payment Records kullanan entegrasyonlara koşullu bir yetenektir. Her mağaza siparişinin tam muhasebe kaydı olduğunu veya ilişkinin tutarı otomatik doğruladığını göstermez. Uygulama yine iç sipariş kimliklerine, sağlayıcı bağlantılarına ve eksik veri kurallarına ihtiyaç duyar.
Bir eşlemeyle başlayın: iç sipariş, Payment Intent, Payment Record ve gerektiğinde tekil denemeler. Kayıtları yalnızca e-posta, benzer tutar veya yakın zaman damgalarıyla eşlemek yerine varlık kimliklerini saklayın. Bu özellikler incelemeyi gerektirebilir, ancak otomatik birleştirme için yeterli değildir.
İptal, bildirilebilir bir sonuca dönüşüyor
Stripe'ın iptal edilen ödemeleri bildirme açıklamasında, ödeme veya ödeme denemesi bildirirken outcome alanına canceled ekleniyor. Önceki değerler guaranteed ve failed idi. outcome: canceled ayarı, canceled_at zaman damgasını içeren canceled parametresini gerektirir.
Stripe, iptal edilen ödeme için tek çağrıyla Payment Record oluşturmayı açıklıyor. Mevcut kayıtta entegrasyon, önceki iki mesajlı sıra yerine iptal edilen denemeyi doğrudan bildirebilir. Bu, sonucun kaydedilme biçimini değiştirir. Bildirimin kendisinin ödeme işlemini iptal ettiği veya para iadesi yaptığı anlamına gelmez.
Dolayısıyla iç sistemdeki “iptal edildi” durumu kesin tanım ister. İptal edilen sipariş, iptal edilen ödeme denemesi ve tamamlanan iade farklı durumlardır. Uygulama hepsini tek alanda tutuyorsa yeni API yeteneği zaten belirsiz bir modele başka bir değer eklemekle kalabilir.
wallet.type kullananları kontrol edin
Üçüncü güncelleme Payment Records ve Payment Attempt Records üzerindeki Link cüzdan ayrıntılarıyla ilgilidir. Stripe, Link kart ödemeleri için link türünü ve isteğe bağlı, null olabilen funding_source_group alanını içeren bir nesneyi ekliyor. Kaynak bu kimliği, onay sırasında belirlenen, anlamı dışarıya kapalı ve değişmez bir değer olarak açıklıyor.
wallet.type değerlerini tek tek ele alan entegrasyon yeni değeri hesaba katmalıdır. Olmayan funding_source_group otomatik ödeme hatasına dönüşmemelidir: alan null olabilir. Kimliği banka adı, müşteri adı veya muhasebe hesabı olarak yorumlamayın; duyuru ona bu anlamları yüklemiyor.
Mutabakat açısından önemli olan, yeni cüzdan gösterimi çıktığında ayrıştırıcının kaydı atmamasıdır. Eşleşen finansman kaynağı grubu, ödeme kimliğinin yerini almaz ve iki işlemin tek siparişe ait olduğunu kanıtlamaz.
Aynı anlama gelen kayıtları karşılaştırın
Müşterinin iki kez ödeme denediği bir abonelik düşünün: ilk deneme başarısız olur, ikincisi doğrulanmış sonuç üretir. Bu açıklayıcı bir senaryodur. Sistem her iki denemeyi saklamalı ve yükümlülüğün yerine getirildiğini kabul etmenin dayanağını ayrıca göstermelidir.
Mutabakatı yapılan her işlem için kimlikleri, tutarı, para birimini, olay zamanını, alınma zamanını ve iyi tanımlanmış durumu saklayın. Tutarları kararlaştırılmış birimlerde karşılaştırın, tutarlı zaman kuralı uygulayın ve yeterli kanıt gelene kadar bilinmeyen sonuçları koruyun. Nihai parasal durumu hangi kaynağın belirlediğini muhasebe sorumlusuyla kararlaştırın.
Karşılaştırmanın sınırı da önemlidir. Ödemenin operasyonel sonucu, sağlayıcının hesaplaşması, ücretler ve muhasebe kaydı farklı zamanlarda kaydedilebilir. Yeni Payment Records alanları bu tutarları eşitlemez. Eşdeğer varlıkları karşılaştırın ve hangi zaman farklarının beklendiğini açıklayın.
Farkı işlem yapılabilir bir göreve dönüştürün
“Eşleşmiyor” diyen rapor yeterli değildir. Nedenleri ayırın: eksik ilişki, bilinmeyen durum, tutar farkı, geç olay veya inceleme gerektiren finansal işlem. Her biri sorumlu ve güvenli sonraki adım ister.
Bir kayıt eksikse yalnızca raporu temizlemek için siparişi ödenmiş işaretlemeyin. İptal bildirildiğinde önce neyin iptal edildiğini ve ayrı bir para hareketi olup olmadığını belirleyin. Yeniden kontrol için özgün kimlikleri ve önceki kararı saklayın. Böylece geçmiş, destek ve finans ekiplerince anlaşılabilir.
Akış, sorumluyu ve sonraki görevi gösteren bir iç iş sisteminin parçası olabilir. API entegrasyonlarıyla veri aktarımı açık durum sözleşmeleri gerektirir. Özel API mimarisi açıklaması, modeller ve ortak kaynaklar hakkında bağlam sağlar; o projede Payment Records kullanıldığını göstermez.
Yayından önce anlamı doğrulayın
Yükseltmede yeni ilişkiyi, zaman damgalı iptal sonucunu, link enum değerini ve null olabilen alanı kontrol edin. Ardından iş senaryolarını deneyin: tek sipariş için iki deneme, eksik kayıt, gecikmiş mesaj ve iadesiz iptal. Amaç teknik olayın finansal doğrulama gibi gösterilmemesidir.
Abonelik ürünlerinde abonelik iptal akışını da inceleyin. Gelecekteki tahsilatı durdurmak ile geçmiş ödemenin sonucunu belirlemek farklı kurallar ister. Mağaza aynı ayrımı sipariş değişiklikleri ve iadelerde korumalıdır.
Ekibin gerçekten inceleyebileceği küçük bir fark kuyruğuyla başlayın. Çözülmemiş vakaların yaşını, ilişki bütünlüğünü ve elle düzeltme nedenlerini ölçün. Bu, belirsizliği tek yeşil durumun arkasına saklamadan sonraki otomasyona temel sağlar.