E-ticarette ve B2B sipariş operasyonlarında asıl sorun çoğu zaman tek bir sistemin eksikliği değildir. Asıl problem, birden fazla sistemin aynı olayı farklı zamanlarda, farklı formatlarda ve farklı kurallarla işlemesidir. Sipariş e-ticaret altyapısında oluşur, ödeme sağlayıcısı işlemi onaylar, kargo sistemi barkod üretir, pazar yeri statü bekler, ERP stok düşer. Bu akışın herhangi bir noktasında veri gecikirse ya da alan eşleşmesi hatalı kurgulanırsa sonuç çoğunlukla aynıdır: iptal edilemeyen siparişler, iki kez düşen stok, yanlış kargo etiketi, muhasebe uyuşmazlığı, müşteri memnuniyetsizliği.

Kargo ödeme entegrasyonu yalnızca teknik bir bağlantı meselesi değildir. Operasyon kuralları, hata yönetimi, veri modeli ve gözlemlenebilirlik birlikte düşünülmelidir. İyi kurgulanmış bir entegrasyon katmanı, 1 siparişin 5 farklı sistemde tek bir gerçeğe bağlı kalmasını sağlar. Yazının odağı da tam olarak bu: kargo, ödeme ve pazar yeri entegrasyonları nasıl yönetilir; veri kopukluğu nasıl önlenir; hangi mimari kararlar sahada gerçekten fark yaratır?

Veri kopukluğu neden oluşur? En sık görülen 6 kırılma noktası

Entegrasyon projelerinde sorun çoğu zaman API bağlantısı kurulduktan sonra başlar. Çünkü bağlantı kurmakla süreci yönetmek aynı şey değildir. Özellikle 4 sistemden fazla temas eden yapılarda, sipariş yaşam döngüsünün nerede başladığı ve hangi kaydın “kaynak sistem” olduğu net değilse çakışma kaçınılmaz olur.

Pratikte en sık karşılaşılan kırılma noktaları şunlardır:

  • Sipariş kimliği uyumsuzluğu: E-ticaret sitesi order_id üretir, ERP farklı belge numarası açar, pazar yeri kendi paket numarasını kullanır.
  • Durum senkronizasyon hatası: “Hazırlanıyor”, “paketlendi”, “faturalandı”, “kargoya verildi” gibi statüler sistemler arasında birebir eşleşmez.
  • Asenkron bildirim eksikliği: Ödeme başarılı olsa da webhook ulaşmaz; sipariş beklemede kalır.
  • Tekrarlı çağrı problemi: Timeout yaşayan istemci aynı isteği yeniden yollar; iki tahsilat ya da çift kargo etiketi oluşur.
  • Stok anlık güncellenmez: Pazar yeri ve B2B portal aynı SKU için son 3 ürünü eşzamanlı satar.
  • İade ve iptal akışları eksik kurgulanır: İlk satış akışı çalışır, ters işlem senaryoları boş kalır.

Örneğin günde 2.000 sipariş işleyen bir operasyonda hata oranı yalnızca %1 olsa bile bu, 20 siparişin manuel incelemeye düşmesi anlamına gelir. Her bir kayıt için 5 dakika harcandığında günlük 100 dakikalık operasyon yükü oluşur. Sorun büyüdükçe insan müdahalesi de katlanarak artar.

Kargo ödeme entegrasyonu için doğru mimari nasıl kurulur?

Sağlıklı bir yapıda her sistem birbiriyle doğrudan ve rastgele konuşmaz. Bunun yerine araya bir entegrasyon katmanı konur. Bu katman bazen iPaaS, bazen özel middleware, bazen de bulut üzerinde çalışan hafif servisler olarak tasarlanır. Kritik nokta şudur: iş kuralları tek bir yerde tanımlanmalı, veri dönüşümleri merkezi olarak yönetilmelidir.

1) Canonical data model kullanın

Her sağlayıcının veri formatına göre içeride yeni alanlar üretmek yerine önce kurum içi ortak veri modelini tanımlayın. Mesela sipariş için şu çekirdek alanlar belirlenebilir: order_number, external_order_id, channel, payment_status, shipment_status, invoice_no, items[]. Ardından her pazar yeri, ödeme kuruluşu ve kargo firması bu modele map edilir.

Basit bir örnek:

{
  "order_number": "WEB-2026-000184",
  "channel": "marketplace_x",
  "payment_status": "paid",
  "shipment_status": "label_created",
  "items": [
    {"sku": "SKU-145", "qty": 2}
  ]
}

Bu yaklaşım, yeni bir kargo firması eklendiğinde tüm sistemi yeniden yazma ihtiyacını ortadan kaldırır. Yalnızca yeni adaptör geliştirilir.

2) Olay tabanlı akış kurun

Sipariş oluştu, ödeme onaylandı, kargo etiketi üretildi, teslim edildi, iade geldi. Bunların her biri bir olaydır. Olay tabanlı mimari, sistemler arası bağımlılığı azaltır. E-ticaret uygulaması ödeme servisinin iç mantığını bilmek zorunda kalmaz; yalnızca payment.succeeded olayını dinler. Aynı olay ERP, CRM veya bildirim servisleri tarafından da işlenebilir.

Özellikle yüksek hacimli yapılarda kuyruk sistemi kullanmak önemlidir. 10 saniyelik geçici servis kesintisi yüzünden sipariş kaybı yaşanmaz; olaylar sırada bekler ve yeniden işlenir.

3) Idempotency zorunludur

Ödeme ve kargo tarafında aynı isteğin ikinci kez işlenmemesi gerekir. Bunun için benzersiz işlem anahtarı tutulur. Örnek olarak Idempotency-Key: WEB-2026-000184-SHIPMENT gibi bir anahtar, aynı sipariş için ikinci barkod üretimini engeller.

Bu küçük detay sahada büyük fark yaratır. Özellikle timeout, retry ve webhook tekrarlarında.

Ödeme entegrasyonlarında tutarlılık nasıl korunur?

Ödeme süreci, “başarılı” ya da “başarısız” kadar basit değildir. 3D Secure yönlendirmesi, provizyon, kısmi iade, chargeback, taksit ayrıntısı, komisyon mutabakatı gibi birçok ara durum vardır. Bu nedenle ödeme statülerini tek satırlık bir alan gibi ele almak yanıltıcı olabilir.

Daha güvenli yaklaşım, ödeme yaşam döngüsünü adım adım izlemektir. En az şu zaman damgaları tutulmalıdır: işlem başlatma, sağlayıcı yanıtı, webhook alma zamanı, siparişe yansıma zamanı. Arada 30 saniye ile 3 dakika arasında fark oluşuyorsa sistem alarm üretmelidir. Çünkü kullanıcı ödeme yaptıktan sonra ekranda “bekleniyor” görmeye devam edebilir.

Bir diğer kritik konu mutabakattır. Banka, ödeme kuruluşu ve ERP kayıtları günlük olarak karşılaştırılmalıdır. Günde 1 kez çalışan otomatik mutabakat raporu bile ciddi riskleri erkenden ortaya çıkarır. Buradaki amaç yalnızca finans ekibine rapor vermek değildir; eksik webhook, yarım kalan iade ya da hatalı sipariş kapatma gibi teknik sorunları da görünür kılmaktır.

Kargo entegrasyonlarında operasyonel sorunlar nasıl azaltılır?

Kargo tarafında sorunlar genellikle adres, desi, servis tipi ve takip numarası etrafında toplanır. API bağlantısı aktif olsa bile yanlış veri yüzünden etiket üretimi durabilir. Türkiye operasyonlarında il, ilçe, mahalle ve posta kodu eşleşmeleri beklenenden fazla hata üretir. Özellikle pazar yerlerinden gelen serbest metin adresler normalize edilmeden doğrudan kargo servisine gönderilirse başarısız istek oranı yükselir.

Burada birkaç somut önlem etkili olur:

  • Adres verisini sipariş anında normalize edin, kargo anına bırakmayın.
  • Desi ve ağırlık bilgisini ürün kartından zorunlu alan olarak yönetin.
  • Tek bir sipariş için çoklu paket senaryosunu baştan modelleyin.
  • Kargo etiketi üretildikten sonra takip numarasını anında sipariş kaydına yazın.

Örnek senaryo: Aynı siparişte 2 koli çıkışı varsa, birçok basit entegrasyon yalnızca tek takip numarasını saklar. Müşteri ilk koliyi teslim alır, sistem siparişi tamamlandı kabul eder, ikinci koli kaybolur. Veri modeli paket bazlı tasarlanmadığında bu tür görünmeyen operasyonel açıklar ortaya çıkar.

Pazar yeri entegrasyonlarında kanal farkları nasıl yönetilir?

Her pazar yerinin sipariş, kargo ve iade mantığı birbirinin kopyası değildir. Bazısında paket statüsü ile sipariş statüsü ayrıdır. Bazısında SLA süresi saat bazında işler. Bazısı stok güncellemesini anlık bekler, bazısı toplu besleme kabul eder. Tek bir “genel pazar yeri servisi” yazıp tüm platformları aynı kabul etmek kısa vadede hızlı görünse de uzun vadede maliyeti artırır.

Daha sürdürülebilir model, ortak çekirdek + kanal adaptörü yaklaşımıdır. Çekirdek servis siparişi, stok hareketini ve fiyat bilgisini yönetir. Kanal adaptörleri ise ilgili platformun özel kurallarını uygular. Yeni bir kanal eklendiğinde yalnızca o adaptör etkilenir.

Burada dikkat edilmesi gereken 2 sayı vardır: API rate limit ve SLA. Örneğin bir pazar yeri dakikada belirli sayıda istek kabul ediyorsa, yoğun kampanya saatlerinde toplu güncelleme kuyruğu tasarlanmalıdır. Aksi halde bazı sipariş durumları geç iletilir, platform cezaları ve görünürlük kaybı gündeme gelir.

B2B operasyonlarında ERP, CRM ve e-ticaret verisi nasıl birleşir?

B2B tarafında entegrasyon daha karmaşıktır. Çünkü yalnızca sipariş değil; bayi fiyat listesi, iskonto kuralı, vade, cari limit, sevkiyat adresi, tekliften siparişe dönüşüm ve onay akışları da devrededir. Burada veri kopukluğu, tekil sipariş hatasından daha büyük sonuçlar üretir. Yanlış iskonto oranı ya da eski fiyat listesi, kârlılığı doğrudan etkiler.

Sağlam bir kurulumda ERP çoğu zaman ürün, fiyat, cari ve stok için ana sistemdir. Web veya mobil B2B portalı ise deneyim katmanıdır. CRM, müşteri ilişkisini ve teklif sürecini taşır. Bunların hangi veride “master” olduğu yazılı hale getirilmelidir. Mesela:

  • Stok ve fiyat: ERP master
  • Müşteri temas geçmişi: CRM master
  • Sepet ve oturum verisi: B2B portal master

Bu tablo basit görünür ama sahada oldukça işe yarar. Ekipler, bir veri uyuşmazlığında nereye bakacağını bilir. Ayrıca her senkron alan için güncelleme yönü de tanımlanmalıdır: tek yönlü mü, çift yönlü mü, olay bazlı mı, saatlik batch mi? Saatte 1 çalışan stok senkronu bazı sektörlerde yeterlidir; hızlı tüketimde 60 dakika çok uzundur.

Gözlemlenebilirlik ve hata yönetimi olmadan entegrasyon tamamlanmış sayılmaz

Canlıya alınan birçok entegrasyon projesi, izleme tarafı eksik bırakıldığı için birkaç ay içinde kırılgan hale gelir. En azından şu metrikler dashboard üzerinde görünmelidir: son 24 saatte gelen sipariş sayısı, başarısız webhook sayısı, kuyrukta bekleyen olay adedi, ortalama işleme süresi, yeniden deneme oranı, kanal bazlı hata dağılımı.

Örneğin “payment.succeeded olayı alındı ama shipment.created 15 dakika içinde oluşmadı” kuralı bir alarm olarak tanımlanabilir. Bu tek alarm bile yüzlerce siparişi tek tek kontrol etme ihtiyacını azaltır.

Log kayıtlarında sipariş numarası, harici işlem kimliği ve kanal bilgisi birlikte tutulmalıdır. Aksi halde destek ekibi 1 siparişin yolculuğunu 5 ayrı ekranda aramak zorunda kalır. İyi entegrasyon görünmeden çalışır; bozulduğunda ise çok hızlı teşhis edilir.

Projeye başlamadan önce sorulması gereken teknik sorular

Başarılı entegrasyon projeleri teknoloji seçimiyle değil, doğru sorularla başlar. İlk analiz toplantısında aşağıdaki başlıklar netleşmelidir:

  • Günlük sipariş hacmi kaç? Kampanya günlerinde en yüksek pik ne kadar?
  • Hangi sistem hangi verinin ana kaynağı?
  • Gerçek zamanlı akması gereken alanlar hangileri?
  • İptal, iade, kısmi sevkiyat, başarısız tahsilat senaryoları nasıl işleyecek?
  • Retry, timeout ve duplicate request nasıl yönetilecek?
  • Operasyon ekibi hatalı kayıtları hangi panelden görecek?

Bu soruların yazılı bir cevabı yoksa entegrasyon kısa sürede “çalışıyor gibi görünen” ama sürekli manuel müdahale gerektiren bir yapıya dönüşür.

Kapanışta net bir çerçeve çizelim: kargo, ödeme ve pazar yeri bağlantıları tek başına değer üretmez. Asıl değeri, bu bağlantıların tutarlı veri modeli, olay tabanlı akış, idempotent işlem mantığı, izleme ve mutabakatla birleşmesi üretir. E-ticaret ya da B2B operasyonu büyüdükçe veri kopukluğunu sonradan yamamak daha pahalı hale gelir. Doğru entegrasyon mimarisi ise yalnızca bugünü değil, yeni kanal ve yeni iş modeli eklendiğinde yarını da taşır.