E-pin ve dijital ürün satışında en büyük darboğaz genelde ödeme veya tasarım değil, tedarik zinciridir. Turkpin, Pinabi gibi yurtdışı menşeli toptancı API'leriyle çalışmaya başladığınız an, elle stok takibi yapan küçük bir mağaza olmaktan çıkıp gerçek zamanlı senkronize olması gereken bir sisteme dönüşürsünüz. Bu rehberde entegrasyonun neresinde işlerin tıkandığını, hangi hataların sipariş iptaline yol açtığını ve Pinova gibi bir altyapının bu süreci nasıl sadeleştirdiğini adım adım anlatıyoruz.
Yurtdışı tedarikçiyle çalışmak neden düşündüğünüzden daha karmaşık?
İlk bakışta iş basit görünür: tedarikçinin API dokümantasyonunu açar, birkaç endpoint'i çağırır, ürünleri sitenize çekersiniz. Ama Turkpin ve Pinabi gibi sağlayıcıların gerçek zorluğu API'nin kendisinde değil, API'nin arkasındaki değişkenlerde saklıdır: anlık stok durumu, kur bazlı fiyatlandırma, bölgesel kısıtlamalar (region-lock) ve tedarikçi tarafında yaşanan geçici kesintiler.
Bir e-pin sitesi için "entegrasyon" tek seferlik bir kurulum değil, sürekli bakım isteyen canlı bir bağlantıdır. Tedarikçi tarafında fiyat güncellenir, siz haberdar olmazsanız zararına satış yaparsınız. Stok tükenir, sisteminiz hâlâ "stokta" yazıyorsa müşteri parasını öder ama kod alamaz. Bu noktada asıl mesele kod yazmak değil, bu değişkenleri otomatik yöneten bir mimari kurmaktır.
- API anahtarı ve IP kısıtlaması: çoğu tedarikçi sabit IP ister, bu da barındırma seçiminizi doğrudan etkiler
- Fiyat listesi formatı: bazı tedarikçiler XML, bazıları JSON REST, bazıları hâlâ CSV bazlı toplu dosya kullanır
- Kimlik doğrulama: API key + secret imzalama, bazen HMAC bazen basit token
- Rate limit: dakikada belirli sayıda istek sınırı, aşımda geçici blok
Turkpin ve Pinabi API'leri gerçekte nasıl işliyor?
Turkpin ve Pinabi, Türkiye'deki e-pin bayilerinin en çok kullandığı iki toptan tedarikçi. İkisi de temelde benzer bir mantıkla çalışır: size bir ürün kataloğu, anlık stok bilgisi ve sipariş oluşturma endpoint'i sunarlar. Ancak detaylarda ayrışırlar.
Turkpin tarafında fiyatlar genellikle USD veya EUR bazlı gelir ve günlük, bazen saatlik güncellenir. Pinabi'de ise kategori yapısı daha derin olduğundan (özellikle oyun içi para birimleri ve bölgesel Steam/PSN kartlarında) doğru ürün eşlemesi yapmak kritik önem taşır — yanlış eşleme, yanlış ülkeye ait bir kodun satılmasına, dolayısıyla müşteri şikayetine yol açar.
Gerçek zorluk şu: bu iki tedarikçiyi aynı anda kullanan bir site, aynı ürünü (örneğin 50 TL'lik bir oyun kartı) hem Turkpin'den hem Pinabi'den farklı fiyatlarla çekebilir. Sisteminiz bu durumda hangi tedarikçiden sipariş vereceğine karar vermek zorundadır — ya sabit öncelik sırasıyla ya da anlık en ucuz/en stoklu seçenek mantığıyla. Bunu elle yönetmek, ürün sayısı 50'yi geçtiği anda pratik olarak imkansız hale gelir.
Manuel stok takibi sizi tam olarak nerede yakalar?
Birçok yeni e-pin girişimcisi işe elle stok takibiyle başlar: tedarikçi panelinden fiyat listesini indirir, Excel'e aktarır, siteye elle girer. Bu yöntem ilk 20-30 üründe idare eder. Ama sipariş hacmi arttığında üç yerde çatlak verir.
Birincisi, stok senkronizasyon gecikmesi. Tedarikçide stok tükendiği anla sizin panelinizde "stokta yok" yazana kadar geçen süre, genelde birkaç saattir. Bu aralıkta gelen siparişler ya iptal edilir ya da müşteri saatlerce beklemek zorunda kalır — ikisi de itibar kaybı demektir.
İkincisi, fiyat gecikmesi. Döviz kuru günde birkaç kez oynayabilir, tedarikçi fiyatını buna göre günceller. Siz elle takip ediyorsanız, kur yükseldiğinde eski fiyattan satış yapmaya devam edip zarar edersiniz; kur düştüğünde ise rakiplerinizden pahalı kalırsınız.
Üçüncüsü, insan hatası. Yüzlerce SKU'yu elle güncellerken yanlış kod, yanlış kategori veya unutulan bir ürün kaçınılmazdır. Otomatik entegrasyonlu bir sistemde bu risklerin büyük kısmı ortadan kalkar çünkü fiyat ve stok bilgisi doğrudan tedarikçi API'sinden çekilip anlık yansıtılır.
| Süreç | Manuel / Elle | Pinova ile |
|---|---|---|
| Stok güncelleme | Panelden indir, Excel'e aktar, siteye gir | API'den otomatik anlık çekim |
| Fiyat/kur takibi | Kur değiştiğinde elle yeniden hesap | Kur bazlı otomatik marj hesaplama |
| Sipariş yönlendirme | Hangi tedarikçiden alınacağına elle karar | Öncelik/stok/fiyat kuralına göre otomatik seçim |
| Kod teslimatı | Sipariş geldiğinde elle tedarikçiden kod alıp gönderme | Ödeme onayından saniyeler sonra otomatik teslim |
| Hata/iade yönetimi | Tek tek e-posta ile takip | Panelden loglu, izlenebilir işlem geçmişi |
Kur farkı ve fiyatlandırma neden gizli bir kâr kaybı kaynağı?
Yurtdışı tedarikçiyle çalışan hemen her e-pin sitesinin gözden kaçırdığı bir nokta var: tedarikçi fiyatı döviz bazlı, siz ise müşteriden TL tahsil ediyorsunuz. Aradaki fark sadece "kur çevirme" meselesi değil, gerçek bir risk yönetimi konusu.
Örneğin sabah 10:00'da tedarikçi fiyatını güncel kurla çekip sitenize TL fiyat olarak sabitlerseniz, akşam kur %2 yükseldiğinde o üründe zarar etmeye başlarsınız — siparişler geldikçe fark büyür. Tersi durumda, kur düşerse siz gereksiz yere pahalı kalırsınız ve satış kaybedersiniz.
Bunun çözümü, statik fiyat yerine dinamik marj mantığı kurmaktır: tedarikçi fiyatı + sabit yüzde kâr payı + güncel kur, her senkronizasyonda yeniden hesaplanır. Böylece kur ne yönde hareket ederse etsin, kâr marjınız sabit kalır. Bu mantığı elle yürütmek pratik değildir; bu yüzden entegrasyon katmanının fiyatlandırma kuralını da içermesi gerekir, sadece stok/kod çekmekle sınırlı kalmamalıdır.
- Sabit TL fiyat: kur riskini tamamen siz üstlenirsiniz
- Sabit yüzde marj + anlık kur: risk dengelenir, kâr marjı korunur
- Kategori bazlı farklı marj: rekabetin yoğun olduğu ürünlerde düşük, niş ürünlerde yüksek marj uygulanabilir
Entegrasyon sürecinde hangi teknik adımlar sıkça atlanıyor?
Bir e-pin sitesi kurarken "API'ye bağlandık, çalışıyor" demek entegrasyonun bittiği anlamına gelmez. Gerçek dünyada gözden kaçan birkaç kritik adım vardır.
Hata yönetimi ve tekrar deneme (retry) mantığı: tedarikçi API'si her zaman kesintisiz çalışmaz. Zaman aşımı, 500 hatası veya geçici bakım anlarında sisteminizin siparişi kuyruğa alıp otomatik tekrar denemesi gerekir — aksi halde müşteri parasını öder ama sipariş "askıda" kalır.
Çift sipariş koruması (idempotency): ödeme onayı iki kez tetiklenirse (örneğin webhook tekrar gönderimi) sistem aynı siparişi tedarikçiden iki kez satın almamalıdır. Bu kontrolün olmaması, gerçek parayla iki kat kod satın almanız anlamına gelir.
Loglama ve izlenebilirlik: bir müşteri "kod gelmedi" dediğinde, hangi tedarikçiden, hangi zaman damgasıyla, hangi yanıtla sipariş verildiğini görebilmeniz gerekir. Log tutmayan sistemlerde bu tür anlaşmazlıklar saatlerce süren manuel araştırmaya dönüşür.
Bölgesel ürün eşleme: özellikle Steam, PSN gibi bölgeye özgü ürünlerde yanlış SKU eşlemesi, müşterinin kendi ülkesinde kullanamayacağı bir kod almasına yol açar — bu da hem iade hem itibar maliyeti demektir.
Yeni bir tedarikçi entegre ederken önce düşük hacimli bir kategoride (örneğin tek bir oyun kartı serisi) canlıya alıp bir hafta izleyin. Stok/fiyat senkronizasyonu ve hata oranı stabil görününce diğer kategorilere genişletin — tüm kataloğu ilk günden bağlamak, küçük bir API tutarsızlığını büyük bir müşteri sorununa dönüştürebilir.
Tedarikçi arızalandığında sitenizde gerçekte ne olur?
Hiçbir yurtdışı API %100 kesintisiz çalışmaz. Turkpin veya Pinabi tarafında planlı bakım, ani trafik yoğunluğu ya da bağlantı sorunu yaşandığında, sisteminizin bu duruma nasıl tepki verdiği işin kaderini belirler.
Kötü kurulmuş bir entegrasyonda şu senaryo yaşanır: müşteri ödemeyi tamamlar, sistem tedarikçiden kod almaya çalışır, API yanıt vermez, işlem "hata" olarak düşer ama müşteriye "ödemeniz alındı, ürününüz gönderiliyor" mesajı zaten gitmiştir. Sonuç: para tahsil edilmiş ama kod teslim edilmemiş bir sipariş, ve bunu fark etmek için birinin panele bakması gerekir.
Doğru kurulmuş bir sistemde bu durum farklı işler: sipariş "bekliyor" statüsünde kuyruğa alınır, birkaç dakika arayla otomatik tekrar denenir, belirli bir sürede çözülmezse hem müşteriye hem yöneticiye bildirim gider ve gerekirse manuel müdahale (alternatif tedarikçiden karşılama veya iade) devreye girer. Aradaki fark, bir yazılımın "API'ye bağlı" olması ile "API arızasına dayanıklı" olması arasındaki farktır — ve bu fark genelde ancak canlıda bir kesinti yaşandığında fark edilir.
- Otomatik kuyruk + tekrar deneme: geçici kesintilerde sipariş kaybolmaz
- Zaman aşımı sonrası bildirim: uzun süren askıdaki siparişler görünür hale gelir
- Alternatif tedarikçi yedekleme: bir kaynak çökerse ikinci kaynaktan karşılama imkânı
- Şeffaf müşteri bilgilendirmesi: "işleminiz gecikiyor" mesajı, sessiz kalmaktan her zaman daha iyidir
Bu entegrasyonu sıfırdan mı kuracaksınız, yoksa hazır altyapıyla mı başlayacaksınız?
Pinova, Turkpin ve Pinabi bağlantısını, kur bazlı otomatik fiyatlandırmayı, hata/tekrar deneme mantığını ve 7/24 otomatik teslimatı kendi sunucunuzda hazır kurulu olarak sunar — sıfırdan API kodu yazmadan.
Turkpin ve Pinabi'yi aynı anda kullanabilir miyim?
Evet, çoğu e-pin sitesi ürün çeşitliliğini artırmak ve fiyat/stok risklerini dağıtmak için birden fazla tedarikçiyi paralel kullanır. Pinova gibi sistemler, aynı ürün için hangi tedarikçiden sipariş verileceğini önceliğe, stok durumuna veya fiyata göre otomatik belirleyebilir.
API bağlantısı kurmak için teknik bilgi şart mı?
Sıfırdan entegrasyon yazmak API dokümantasyonu okuma ve kod geliştirme gerektirir. Hazır bir altyapı kullanıldığında ise genellikle sadece API anahtarınızı panelden girmeniz yeterli olur; teknik geliştirme ihtiyacı ortadan kalkar.
Tedarikçi fiyatları değiştiğinde sitem otomatik güncellenir mi?
Doğru kurulmuş bir entegrasyonda evet — fiyat ve stok bilgisi belirli aralıklarla (genelde dakikalar seviyesinde) tedarikçi API'sinden yeniden çekilip sitenize yansıtılır, elle müdahaleye gerek kalmaz.
Tedarikçi API'si geçici olarak çökerse siparişlerim ne olur?
İyi kurulmuş bir sistemde sipariş kaybolmaz; kuyruğa alınıp otomatik olarak tekrar denenir. Belirli bir süre çözülmezse hem müşteri hem yönetici bilgilendirilir ve manuel müdahale imkânı sağlanır.