Sanal pos entegrasyonu: siteye ve uygulamaya ödeme nasıl eklenir?

Sanal pos entegrasyonu, web sitenizin ya da uygulamanızın kartla ödeme almasını sağlayan bağlantıdır: siparişi oluşturan sizin yazılımınızdır, kart bilgisini alan ve bankadan onayı isteyen ise banka ya da lisanslı ödeme kuruluşudur. Ortak ödeme sayfası ya da gömülü form kullanan bir entegrasyonda kart numarası sizin sunucunuza uğramaz; sizin işiniz siparişi, ödeme sonucunu, iadeyi ve günlük mutabakatı hatasız yönetmektir.

Sanal pos entegrasyonu bir eklentiyi açmaktan fazlasıdır, çünkü ödemedeki küçük bir hata çift çekim ya da kayıp sipariş olarak geri döner. Ben olsam işe sağlayıcı seçmekle değil, ödeme sonucunun sisteme nasıl yazılacağını ve bir şey ters gittiğinde kimin neye bakacağını yazıya dökmekle başlardım. Yazıdaki hukuki ve teknik bilgiler Ekim 2026 itibarıyla resmî kaynaklardan kontrol edildi.

Sanal pos entegrasyonu nedir ve ödeme akışı adım adım nasıl işler?

Sanal pos entegrasyonu, internetten verilen bir siparişin kart ödemesine dönüşmesi için sitenizin ödeme sağlayıcısıyla konuştuğu yazılım parçasıdır. Müşteri için tek bir "Öde" düğmesi gibi görünen akış, arka planda en az üç tarafın birbirine mesaj göndermesiyle tamamlanır: sizin sunucunuz, ödeme sağlayıcısı ve kartı çıkaran banka. Bu yazıda "ödeme sağlayıcısı" derken hem bankaların sanal pos hizmetini hem de TCMB'den izinli ödeme ve elektronik para kuruluşlarını kastediyorum.

1. Müşteri sepeti onaylar; sizin sisteminiz tutarı ve sipariş numarasını kaydeder ve siparişi "ödeme bekliyor" durumuna alır.
2. Sunucunuz ödeme sağlayıcısına bir ödeme oturumu açtırır ve müşteriyi sağlayıcının ödeme sayfasına ya da sitenize gömülü ödeme formuna yönlendirir.
3. Müşteri kart bilgisini o sayfaya girer; kartı çıkaran banka gerekirse 3D Secure doğrulaması ister.
4. Banka işlemi onaylar ya da reddeder; sağlayıcı sonucu tarayıcıyı sitenize geri göndererek ve ayrıca sunucunuza bir bildirim (callback) yollayarak iletir.
5. Sunucunuz sonucu sağlayıcıdan doğrular ve siparişi "ödendi" ya da "başarısız" olarak işaretler.
6. Gün sonunda sağlayıcının işlem raporu ile sizin sipariş kayıtlarınız karşılaştırılır; buna mutabakat denir.

Sanal pos ödeme akışında siparişin kaydı, ödeme oturumunun açılması, sonucun doğrulanması ve mutabakat sizin yazılımınızın sorumluluğundadır. Bence bir entegrasyonun kalitesi, ödeme başarılı olduğunda değil, banka onayı ile sunucunuzun bu onayı doğrulaması arasında bağlantı koptuğunda belli olur. Sistemlerin birbirine nasıl bağlandığını ilk kez düşünüyorsanız API nedir rehberimizdeki istek, yanıt ve webhook anlatımı bu akışı okumayı kolaylaştırır.

Banka sanal posu mu, ödeme kuruluşu mu seçmelisiniz?

Banka sanal posu ile ödeme kuruluşu arasındaki seçim, kiminle sözleşme yaptığınızı, kaç entegrasyon yazacağınızı ve parayı hangi koşullarla alacağınızı belirler. 6493 sayılı Kanun'un 13. maddesi Ekim 2026 itibarıyla ödeme hizmeti sağlayıcılarını bankalar, elektronik para kuruluşları, ödeme kuruluşları ve PTT olarak sayar; Merkez Bankası ve bu sağlayıcılar dışındaki kişilerin ödeme hizmeti sunamayacağını söyler (6493 sayılı Kanun, mevzuat.gov.tr (yeni sekmede açılır)).

6493 sayılı Kanun'un 14. maddesine göre bir ödeme kuruluşu ancak Türkiye Cumhuriyet Merkez Bankası'ndan (TCMB) izin alarak faaliyet gösterebilir. Bu nedenle bir ödeme kuruluşuyla anlaşmadan önce adının TCMB'nin faaliyetteki ödeme kuruluşları listesinde (yeni sekmede açılır) yer aldığını kontrol edin; elektronik para kuruluşları TCMB'nin ayrı bir listesinde yer alır. Liste Ekim 2026 itibarıyla her kuruluşun Kanun'un 12. maddesindeki hangi hizmetler için yetkili olduğunu bent harfleriyle gösterir. Kartla ödeme almak için bakmanız gereken (c) bendidir; TCMB'nin notuna göre ödeme kuruluşlarında bu bendin kapsamı yalnızca "ödeme aracının kabulü"dür.

Banka sanal posu ile ödeme kuruluşu arasındaki teknik fark şudur: banka sanal posunda o bankanın entegrasyon dokümanına göre çalışırsınız ve birden fazla bankayla çalışmak isterseniz her banka en azından ayrı bir sözleşme, ayrı bir test ve ayrı bir mutabakat demektir. Ödeme kuruluşunda tek bir arayüzle çalışırsınız; kuruluşun hangi taksit ve kart seçeneklerini sunduğu ise sözleşmesine bağlıdır. Banka sanal posunda da ödeme kuruluşunda da komisyon, valör ve taksit koşulları sözleşmeyle belirlenir; bu yazıda hiçbir oran vermiyorum, çünkü oranlar sağlayıcıya, sektöre ve hacme göre değişir.

Banka sanal posu, ödeme kuruluşu ve hazır e-ticaret altyapısının ödeme modülü, entegrasyon işi açısından şöyle karşılaştırılır:

Banka sanal posu ile ödeme kuruluşu arasındaki seçimi sadeleştirmek için şu ölçütleri kullanırdım:

• Banka sanal posu uygundur: işletmenizin zaten güçlü bir banka ilişkisi varsa, taksit kampanyalarınız belirli bir bankanın kartlarına bağlıysa ve ayrı bir entegrasyonu bakımıyla birlikte üstlenecek bir yazılım ekibiniz varsa.
• Ödeme kuruluşu uygundur: tek entegrasyonla hızlı başlamak ve kuruluş sunuyorsa kart saklama ya da abonelik gibi özellikleri hazır almak istiyorsanız.
• İki sağlayıcı birlikte düşünülmelidir: ödeme kesintisinin satışı doğrudan durdurduğu bir işiniz varsa; bu durumda yazılımın sağlayıcıdan bağımsız bir ara katmanla yazılması gerekir.

3D Secure ödeme akışında neyi değiştirir?

3D Secure, kart sahibinin internet alışverişinde kartı çıkaran banka tarafından doğrulanmasını sağlayan protokoldür ve yazılımınız açısından ödemeye bir yönlendirme ile bir dönüş adresi ekler. Standardı yöneten EMVCo'nun sitesindeki açıklama, Ekim 2026 itibarıyla, pek çok işlemin ek adım olmadan ("frictionless") onaylanabildiğini, yüksek riskli işlemlerde ise bankanın ek doğrulama isteyebildiğini anlatıyor ve 2.2 ya da üzeri sürümü öneriyor (EMVCo, EMV 3-D Secure (yeni sekmede açılır)).

3D Secure'un yazılım tarafında üç sonucu vardır. Müşteri bankanın doğrulama ekranına gider ve oradan sitenize geri döner; bu sırada oturum kaybolabilir, sekme kapanabilir ya da mobil uygulama arka plana düşebilir. Dönüş sayfasına gelen "başarılı" bilgisi tek başına güvenilir değildir; sonucu sunucunuzdan sağlayıcıya ayrıca sormanız gerekir. Bir de doğrulamanın başarısız olduğu durumda müşteriye ne söyleneceği ve siparişin ne kadar süre "ödeme bekliyor" durumunda kalacağı önceden kararlaştırılmalıdır.

3D Secure akışında en çok önemsediğim şey, müşteriyi doğrulama ekranından sonra boş ya da belirsiz bir sayfada bırakmamaktır. Ödeme sonucu henüz kesinleşmediyse "ödemeniz kontrol ediliyor" diyen ve birkaç saniye sonra durumu yeniden soran bir ekran, panikleyen müşterinin ikinci kez ödemeye çalışmasının doğuracağı sorundan çok daha ucuzdur.

Ortak ödeme sayfası mı, sitenize gömülü form mu, doğrudan API mi?

Ödeme formunun nerede durduğu, kart verisinin sizin sistemlerinizden geçip geçmeyeceğini ve dolayısıyla PCI DSS yükünüzü belirleyen ana karardır. PCI DSS (Ödeme Kartı Sektörü Veri Güvenliği Standardı), kart sahibi verisini saklayan, işleyen veya ileten kuruluşlara uygulanan teknik ve operasyonel güvenlik gereksinimleri bütünüdür; PCI Security Standards Council'in sayfasına göre standart Ekim 2026 itibarıyla 4.x sürümündedir (PCI DSS, PCI SSC (yeni sekmede açılır)).

Kart ödemesi alan işletmeler uyumlarını bir öz değerlendirme anketiyle (SAQ) beyan edebilir; hangi anketin uygun olduğunu anlaşma yaptığınız banka ya da sağlayıcıyla teyit etmeniz gerekir. En hafif anket SAQ A'dır. PCI SSC'nin 30 Ocak 2025 tarihli duyurusuna göre SAQ A, kart verisi işlevlerini tamamen dışarıya devreden ve kart verisini kendi sistemlerinde elektronik olarak saklamayan, işlemeyen ve iletmeyen satıcılar içindir (PCI SSC, SAQ A güncellemesi (yeni sekmede açılır)). PCI DSS v4.0 için yayımlanan SAQ A metni, e-ticarette ödeme sayfasının tüm öğelerinin doğrudan uyumlu sağlayıcıdan gelmesini de koşul olarak sayar (PCI DSS v4.0 SAQ A (yeni sekmede açılır)).

Sağlayıcının formunu sitenize iframe ile gömüyorsanız SAQ A için ek bir koşul geçerlidir: PCI SSC'nin 28 Şubat 2025 tarihli duyurusuna göre, SAQ A'yı kullanmak isteyen bu satıcılar 1 Nisan 2025'ten itibaren sayfalarının betik (script) saldırılarına karşı korunduğunu teyit etmelidir; bu teyit, sayfanıza uygulanan önlemlerle ya da formu sağlayan uyumlu sağlayıcının, talimatlarına göre kurulduğunda çözümünün bu korumayı içerdiğini teyit etmesiyle yapılabilir; bu teyidi yazılı almanızı öneririm (PCI SSC duyurusu (yeni sekmede açılır)).

Ortak ödeme sayfası, gömülü form ve doğrudan API; kart verisinin geçtiği yer, güvenlik yükü ve tasarım kontrolü açısından şöyle karşılaştırılır:

Ortak ödeme sayfası, gömülü form ve doğrudan API arasındaki kararı şöyle verirdim:

• Ortak ödeme sayfası uygundur: ilk kez ödeme alıyorsanız, güvenlik yükünü en aza indirmek istiyorsanız ve ödeme ekranının sağlayıcının tasarımında görünmesi sizin için sorun değilse.
• Gömülü form uygundur: müşterinin sitenizden ayrılmaması önemliyse ve ödeme sayfanızdaki betikleri düzenli olarak denetleyecek birini görevlendirebiliyorsanız ya da sağlayıcınız bu korumayı yazılı olarak teyit ediyorsa.
• Doğrudan API uygundur: kart verisini işleyecek altyapıyı ve bunun denetimini bilerek üstleniyorsanız; küçük ve orta ölçekli bir işletmenin buna nadiren ihtiyaç duyacağını düşünüyorum.

Kart numarası ve CVV neden yazılımınızda hiç tutulmamalı?

Kart numarasını ve güvenlik kodunu (CVV) saklamamak, sanal pos entegrasyonunun hem hukuki hem teknik olarak en net kuralıdır. 5464 sayılı Banka Kartları ve Kredi Kartları Kanunu'nun 23. maddesi, Ekim 2026 itibarıyla üye işyerlerinin kartın kullanımı sonucunda edindikleri kart ve kart hamili bilgilerini, kanunla yetkilendirilenler dışında, kart hamilinin yazılı rızası olmadan açıklayamayacağını, saklayamayacağını ve kopyalayamayacağını söyler (5464 sayılı Kanun (yeni sekmede açılır)).

5464 sayılı Kanun'un 18. maddesi, üye işyerlerinin iletişim araçları üzerinden işlem yapmak için kurdukları sistemlerin güvenli çalışmasını sağlamakla yükümlü olduğunu yazar; 39. madde ise 23. maddeye kasten aykırılık için hapis ve adli para cezası öngörür. PCI SSC'nin SAQ A metni de kart doğrulama kodunu "hassas kimlik doğrulama verisi" olarak sayar. Kart sahibine ait bilgiler kişisel veri de sayılabileceğinden, 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun (KVKK) 12. maddesi, veri sorumlusunun kişisel verilere hukuka aykırı erişimi önlemek için gerekli teknik ve idari tedbirleri almasını ister (6698 sayılı Kanun (yeni sekmede açılır)).

Kart verisi bilinçli bir kararla değil, gözden kaçan bir ayarla da saklanabilir. Bir yazılım ekibinden şu yerlerin temiz olduğunu göstermesini isterdim:

• Uygulama kayıtları (log): Ödeme isteğinin ya da yanıtının tamamını kaydeden bir hata ayıklama satırı, kart numarasını düz metin olarak dosyaya yazabilir.
• Hata izleme ve analiz araçları: Form alanlarını otomatik toplayan bir betik, kart alanlarını da üçüncü bir tarafa gönderebilir.
• Destek kanalları: Müşteriden e-posta ya da mesajla kart bilgisi istenmemeli, gelirse silinmelidir.
• Veritabanı yedekleri: Bir kez yanlışlıkla yazılan kart verisi, ana tablodan silinse bile eski yedeklerde kalır.

Tekrarlayan ödeme ya da kayıtlı kart gerekiyorsa kart sağlayıcıda kalır ve sizin sisteminiz yalnızca sağlayıcının verdiği bir anahtarı (token) ve işlem numarasını tutar. Kayıtlı kartın hukuki çerçevesi, rıza metni ve saklama süresi için bir avukata danışmanızı öneririm; bu yazı hukuki görüş değildir. Sitenizin genel KVKK düzeni için web sitesi KVKK kontrol listemize bakabilirsiniz.

Callback geç ya da iki kez gelirse çift çekim nasıl önlenir?

Çift çekimi ve kayıp siparişi önlemenin yolu, her ödeme sonucunu bir kez işleyen (idempotent) ve sonucu tarayıcıya değil sağlayıcıya soran bir sunucu mantığıdır. Ödeme sağlayıcıları sonucu hem müşterinin tarayıcısını sitenize geri yönlendirerek hem de sunucunuza bir bildirim göndererek iletebilir; bu iki mesaj farklı sırada, gecikmeyle ya da birden fazla kez gelebilir.

Ödeme bildiriminde çift çekime ya da kayıp siparişe yol açabilecek durumlar şunlardır: müşteri ödeme düğmesine iki kez basar, banka ekranından sonra bağlantısı kopar, bildirim sunucunuz yeniden başlarken gelir ya da sağlayıcı yanıt alamadığı için aynı bildirimi tekrar yollar. Çift çekimi önlemek için vazgeçmeyeceğim dört kural şunlar:

1. Her sipariş için tek bir ödeme referansı üretin ve aynı sipariş için ikinci bir ödeme oturumu açılmadan önce ilkinin durumunu kontrol edin.
2. Bildirimin imzasını ya da doğrulama değerini sağlayıcının dokümanındaki yönteme göre kontrol edin; tutmayan bildirimi işlemeyin.
3. Siparişi "ödendi" yapmadan önce sonucu ve tutarı sağlayıcının sorgulama arayüzünden ayrıca teyit edin.
4. Sipariş durumunu yalnızca beklenen geçişlerle değiştirin: "ödeme bekliyor" durumundan "ödendi" durumuna bir kez geçilir, ikinci bildirim yalnızca kayda alınır.

Çift çekimi önleyen idempotent bildirim mantığı kısa bir TypeScript işleviyle gösterilebilir; örnek belirli bir sağlayıcıya ait değildir ve sadeleştirilmiştir.

// Ödeme bildirimi: aynı bildirim iki kez gelse de sipariş bir kez onaylanır
async function handlePaymentCallback(body: CallbackBody) {
  if (!verifySignature(body)) return reply(400);          // imza tutmuyorsa işleme alma
  const order = await db.orders.findByPaymentRef(body.paymentRef);
  if (!order) return reply(404);
  if (order.status === "paid") return reply(200);         // daha önce işlendi
  const result = await provider.queryPayment(body.paymentRef); // sonucu sağlayıcıya sor
  if (result.status === "success" && result.amount === order.amount) {
    await db.orders.markPaidIfPending(order.id);          // koşullu, tek seferlik güncelleme
  }
  return reply(200);
}

Ödeme bildirimi (callback) hiç gelmezse ne olacağı da tasarımın parçasıdır. "Ödeme bekliyor" durumunda belirli bir süreden uzun kalan siparişleri sağlayıcıya soran zamanlanmış bir görev, kaybolan bildirimleri yakalamanın en basit yoludur. Webhook ve tekrar deneme mantığının temelleri API rehberimizde daha genel bir çerçevede anlatılıyor.

İade, iptal ve mutabakat yazılımda nasıl yönetilir?

İade, iptal ve mutabakat, ödemenin alındığı andan sonra başlayan ve muhasebenin güvendiği kayıtları üreten işlemlerdir. İptal ile iade, sağlayıcıların dokümanlarında ayrı işlemler olarak geçer ve hangisinin hangi zaman aralığında kullanılabileceği sağlayıcıya göre değişir. İptal ve iade için geçerli süre kuralını entegrasyondan önce sağlayıcıdan yazılı olarak alın ve yazılımda "iptal mümkün değilse iade et" mantığıyla işleyin.

Kısmi iade, tek siparişte birden fazla ödeme ve taksitli işlemler iptal ve iade kurallarını karmaşıklaştırır. Yazılımınızın her iade için hangi siparişe, hangi tutarla, kimin onayıyla yapıldığını kaydetmesi gerekir. Mağaza çalışanının panelden iade başlattığı bir sistemde yetki ve onay adımı, ödeme entegrasyonunun kendisi kadar önemlidir; aksi hâlde bir yazım hatası sizin hesabınızdan para çıkarır. Kart hamilinin bankası üzerinden itiraz ettiği işlemler (ters ibraz) için sağlayıcının hangi belgeyi hangi sürede istediğini sözleşmeden öğrenin ve sipariş, teslimat ve iletişim kayıtlarını buna göre saklayın.

Mutabakat, sağlayıcının işlem raporu ile sizin sipariş kayıtlarınızın her gün karşılaştırılmasıdır. Ben bu karşılaştırmanın şu üç listeyi üretmesini isterdim:

• Sağlayıcıda ödenmiş görünen ama sizde ödenmemiş duran siparişler: en olası neden kaybolan bir bildirimdir ve müşteri ürününü bekliyordur.
• Sizde ödenmiş görünen ama sağlayıcı raporunda bulunmayan siparişler: en tehlikeli gruptur, çünkü parası alınmamış bir ürün kargoya verilebilir.
• Tutarı ya da durumu iki tarafta farklı olan işlemler: kısmi iadeler, taksit farkları ve kur farkları burada çıkar.

Ödeme onaylandıktan sonra e-Arşiv ya da e-Fatura düzenlenmesi de sanal pos entegrasyonundaki ödeme, sipariş ve muhasebe zincirinin bir halkasıdır; iade olduğunda faturanın ve muhasebe kaydının nasıl düzeltileceğini mali müşavirinizle netleştirin. Bu bağlantı e-Fatura entegrasyonu rehberimizde ayrıca ele alınıyor.

Canlıya geçmeden önce ne test edilmeli, sonra ne izlenmeli?

Canlıya geçmeden önce sanal pos entegrasyonunda başarılı ödemeden çok hata, tekrar eden bildirim ve iade senaryoları test edilmeli; canlıya geçtikten sonra ise ödeme başarı oranı, bekleyen siparişler ve mutabakat farkları izlenmelidir. Sağlayıcıların test ortamı, para hareket etmeden başarılı, başarısız ve 3D Secure doğrulamalı işlemleri denemenize izin verebilir; neyin sunulduğunu ve canlıya geçiş adımlarını sağlayıcınızın dokümanından teyit edin. Canlıya geçişi ayrı anahtarlar, ayrı adresler ve küçük bir gerçek işlemle yapardım. Benim gözümde test ortamında yalnızca başarılı ödemeyi denemek, testin yarısını atlamak demektir.

Test ortamında hangi senaryolar denenmeli?

Sanal pos test ortamında başarılı ödemeden çok hata senaryoları denenmelidir. Canlıya geçiş onayı vermeden önce şu senaryoların her birinin kaydını görmek isterdim:

1. Başarılı ödeme, kartın reddedildiği ödeme ve 3D Secure doğrulamasının başarısız olduğu ödeme.
2. Müşterinin banka ekranında sekmeyi kapattığı ve hiç geri dönmediği ödeme.
3. Aynı bildirimin iki kez ve gecikmeyle geldiği durum; siparişin bir kez onaylandığı kontrol edilir.
4. İmzası hatalı bir bildirim; işlenmediği kontrol edilir.
5. Tam iade, kısmi iade ve iptal; her biri hem sizde hem sağlayıcı panelinde aynı görünmelidir.
6. Canlı anahtarların kod deposunda değil, gizli bilgi yönetiminde durduğu ve test anahtarlarıyla karışmadığı.
7. Canlıda küçük tutarlı gerçek bir ödeme ve aynı ödemenin iadesi.

Canlıdaki ödeme sistemi nasıl izlenir?

Canlıdaki sanal pos entegrasyonu; başarılı ve başarısız ödeme dağılımı, uzun süre bekleyen siparişler, eşleşmeyen bildirimler, mutabakat farkları ve sertifika süreleri için kurulan uyarılarla izlenir. Bu göstergelerin anlamı şöyledir:

• Başarılı ve başarısız ödeme dağılımı: ani bir değişiklik bir sağlayıcı ya da 3D Secure sorununun ilk işareti olabilir.
• Uzun süre "ödeme bekliyor" durumunda kalan siparişler: kaybolan bildirimlerin ilk belirtisidir.
• Eşleşmeyen bildirimler: hiçbir siparişe bağlanamayan ödeme mesajları ayrıca incelenmelidir.
• Mutabakat farkları: günlük raporun boş olması beklenir, dolu olduğu gün biri bakmalıdır.
• Anahtar, sertifika ve alan adı süreleri: süresi dolan bir sertifika ödeme sayfasını sessizce durdurabilir.

Ödeme izleme göstergelerinin bir sahibi olmalı; yazılım ekibi uyarıyı kurar, ama hangi farkın muhasebeye, hangisinin müşteri hizmetlerine gideceğine işletme karar verir.

Sanal pos projelerinde hangi hatalardan kaçınılmalı?

Sanal pos projelerinde kaçınılması gereken hatalar, ödeme akışının yalnızca başarılı senaryoya göre yazılmasından doğar:

• Siparişi tarayıcının dönüş sayfasına bakarak "ödendi" yapmak.
• Hata ayıklama için açılan ayrıntılı kayıtları canlıda kapatmayı unutmak.
• İade yetkisini panelde herkese açık bırakmak.
• Mutabakatı ay sonuna bırakıp farkları haftalar sonra aramak.
• Sağlayıcı sözleşmesini yazılım ekibine göstermeden imzalamak; teknik kısıtlar sonradan çıkar.

Sanal pos entegrasyonunun süresini ve maliyetini ne belirler?

Sanal pos entegrasyonunun süresi ve maliyeti, bağlantının kendisinden çok, etrafındaki sipariş, iade, mutabakat ve yetki kurallarının ne kadar özel olduğuna bağlıdır. Bu yazıda fiyat aralığı vermiyorum; sizin için önemli olan, hangi kalemin işi büyüttüğünü bilip teklifleri buna göre karşılaştırmaktır. Ödemenin bir e-ticaret bütçesindeki yeri için e-ticaret sitesi kurma maliyeti yazımıza bakabilirsiniz.

Sanal pos entegrasyonunun süresini ve maliyetini büyüten başlıca kalemler şunlardır:

• Ödeme sayfası modeli: ortak ödeme sayfası en az işi, gömülü form ek güvenlik kontrolünü, doğrudan API ise en geniş güvenlik sorumluluğunu getirir.
• Sağlayıcı sayısı: ikinci bir sağlayıcı, ara katman, ayrı test ve ayrı mutabakat demektir.
• Taksit, kayıtlı kart ve abonelik: her biri ayrı ekranlar, ayrı hata durumları ve ayrı iade kuralları getirir.
• Mobil uygulama: uygulama içinde ödeme sayfasının nasıl açılacağı ve uygulamaya nasıl dönüleceği ayrıca tasarlanır; bu iş mobil uygulama hizmetimizin kapsamına girer.
• Bağlı sistemler: ödemeden sonra stok, kargo, muhasebe ya da e-Fatura tetikleniyorsa her biri ayrı bir entegrasyondur.

Ödeme işini hazır bir e-ticaret altyapısının modülüne mi bırakacağınız, yoksa kendi yazılımınızın içinde mi kuracağınız da maliyeti değiştirir. Ben olsam yapay zekâ destekli geliştirmenin ilk sürümün yazımını hızlandırabileceğini, ama test ve izleme işini azaltmayacağını varsayarak plan yapardım. Kendi yazılımınızda kurulan entegrasyon ile hazır e-ticaret altyapısının ödeme modülü, ödeme kuralları, bağlı sistemler, sağlayıcı değiştirme ve maliyet açısından şöyle karşılaştırılır; özel yazılımın üstünlükleri kadar bedelini de yazdım:

Teklif alırken yazılım ekibine hangi soruları sormalısınız?

Bir yazılım ekibinin sanal pos entegrasyonuna hâkim olup olmadığını en iyi hata durumlarına verdiği yanıtlar gösterir. Görüşmeye şu sorularla gidin:

• Ödeme sonucunu hangi kaynaktan doğruluyorsunuz: tarayıcı dönüşünden mi, sunucu bildiriminden mi, sorgulama arayüzünden mi?
• Aynı bildirim iki kez gelirse ya da hiç gelmezse sistem ne yapıyor?
• Kart verisinin kayıtlara, hata izleme araçlarına ve yedeklere düşmediğini nasıl kanıtlıyorsunuz?
• İade ve iptal için panelde kimin yetkisi olacak, her işlem nasıl kayıt altına alınacak?
• Günlük mutabakat raporu otomatik mi üretiliyor, farkları kim görüyor?
• Sağlayıcıyı değiştirmek istersek hangi kod değişir, kayıtlı kartlara ne olur?
• Kaynak kod, sunucu, sağlayıcı paneli ve canlı anahtarlar kimin adına olacak?

Sanal pos teklif sorularının yanıtlarının sözleşmeye nasıl yazılacağı yazılım hizmet sözleşmesi kontrol listemizde madde madde anlatılıyor.

UlvionTech bir sanal pos entegrasyonunu nasıl kurardı?

UlvionTech'in sanal pos entegrasyonu için önerdiği yol, tek sağlayıcı ve ortak ödeme sayfasıyla sade bir başlangıç ile hata durumlarını baştan karşılayan bir sunucu mantığıdır. Ben olsam önce ödeme kurallarını yazıya dökerdim: hangi ürün ya da hizmet için ne zaman, ne kadar ve hangi koşulla ödeme alınacağı, iadenin kimin onayıyla yapılacağı ve mutabakat farklarının kime gideceği. Kodlamaya bu yazılı kapsamdan sonra başlardım; UlvionTech'te sabit fiyat da bu yazılı kapsama göre verilir.

İlk sürümde lisansı TCMB listesinden kontrol edilmiş tek bir sağlayıcı ve onun ortak ödeme sayfasıyla başlardım. Sağlayıcıyla konuşan kodu ayrı bir katmanda tutardım; böylece ileride ikinci bir sağlayıcı ya da gömülü form eklemek, sipariş mantığını yeniden yazmayı gerektirmez. İdempotent bildirim işleme, sonucu sağlayıcıya ayrıca sorma, bekleyen siparişleri tarayan zamanlanmış görev ve günlük mutabakat raporu ilk sürüme dahil olurdu; bunları sonraya bırakmazdım.

Kaynak kod, sunucu, alan adı, sağlayıcı paneli ve canlı anahtarlar sizin adınıza açılır; bu, çalışma ilkelerimizden biridir. Bu tür bir entegrasyon web uygulamaları hizmetimizin kapsamındadır. Abonelikle satış yapan bir ürün planlıyorsanız tekrarlayan ödemenin ürün tarafı SaaS nasıl yapılır yazımızda anlatılıyor; kapora alan bir randevu sistemi için online randevu sistemi rehberimiz daha uygun bir başlangıçtır.

Hangi durumda kendi sanal pos entegrasyonunuzu yaptırmamalısınız?

Kendi entegrasyonunuzu yaptırmak, ödeme kurallarınız hazır çözümlere sığmıyorsa ya da ödeme başka sistemlerinizle sıkı bağlıysa anlamlıdır; aksi durumda hazır bir yol yeterlidir. Şu durumlarda ayrı bir yazılım yaptırmamanızı önerirdim:

• Az sayıda ürün satıyor ve hazır bir e-ticaret altyapısı kullanıyorsanız: altyapının ödeme modülü, ayrı bir yazılım projesinden daha az iş ve daha az risk getirir.
• Ödeme seyrek ve tutarlar belliyse: sağlayıcının ödeme bağlantısı (link) özelliği ya da panelinden gönderilen bir ödeme sayfası, sitenizde hiçbir kod değişikliği gerektirmeyebilir.
• Başka satıcılar adına para toplayıp dağıtmak istiyorsanız: 6493 sayılı Kanun'un 13. maddesi ödeme hizmeti sunabilecek kuruluşları bankalar, elektronik para kuruluşları, ödeme kuruluşları ve PTT olarak sayar; modelinizin bu kapsama girip girmediğini kurmadan önce bir avukatla değerlendirmeniz ve lisanslı bir sağlayıcının bu iş için sunduğu çözümü sormanız gerekir.
• Kendi yazılım ekibiniz ödeme entegrasyonunu daha önce kurmuş ve işletiyorsa: bizim yerimize ekibinizin bu yazıdaki kontrol listesini kullanması yeterli olabilir.

Ödemenin siparişler, faturalar ve iadelerle birlikte nasıl akacağını belirlemek istiyorsanız, hangi kanallardan satış yaptığınızı ve ödemeyi hangi koşullarla aldığınızı bize yazarak anlatabilirsiniz; hangi parçanın sağlayıcıda, hangisinin sizin yazılımınızda kalacağını birlikte çıkarırız.

Fotoğraf kredisi: kapak fotoğrafı, Shixart1985 (Wikimedia Commons) (yeni sekmede açılır) ve klavye fotoğrafı, Shixart1985 (Wikimedia Commons) (yeni sekmede açılır), lisans: CC BY 2.0 (yeni sekmede açılır); veri merkezi fotoğrafı, The National Archives (UK) (Wikimedia Commons) (yeni sekmede açılır), lisans: CC BY 3.0 (yeni sekmede açılır). Fotoğraflar kırpıldı.