MevvPos — Mevvsoft Belgeleri

Kurulum

MevvPos WordPress 6.0+ ve PHP 8.1+ istiyor. WooCommerce isteğe bağlı. WooCommerce 9.0 ya da üstü etkinken MevvPos kendini ödeme sayfasında bir ödeme yöntemi olarak kaydediyor; WooCommerce yokken de ödeme motoru yükleniyor ve başka bir eklenti tarafından sürülebiliyor. Önceki sürümlerde WooCommerce zorunlu bir bağımlılık olarak bildiriliyordu ve o olmadan WordPress eklentiyi etkinleştirmiyordu — o şart kalktı.

WooCommerce'in iki ödeme yüzeyi de kapsanıyor. MevvPos hem klasik kısa kodlu ödeme sayfasına hem de yeni Ödeme bloğuna kendini kaydediyor. 4.7.1'e kadar yalnız klasik sayfa bağlıydı; blok ödemeye geçen bir mağazada kart seçeneği tamamen kayboluyordu — hata yok, uyarı yok, yalnız eksik bir ödeme yöntemi. Ayrıca ayarlanacak bir şey yok: blok sayfasında kart alanları, taksit tablosu ve taksit komisyonu aynı biçimde çıkıyor.

Eklentiyi Eklentiler → Yeni Ekle → Eklenti Yükle altından yükleyip etkinleştirin.
Sol menüden MevvPos ekranını açın. WooCommerce altında da bir kısayolu vardır; satıcılar ödeme ayarlarını orada arıyor.
Genel sekmesinden ödeme yöntemini açın ve müşterinin ödeme sayfasında göreceği başlığı yazın.
Bank API sekmesinde sağlayıcınızı seçin — bir Türk banka sanal POS'u ya da uluslararası sağlayıcıdan biri — ve size verdiği kimlik bilgilerini girin.
Uluslararası bir sağlayıcı seçtiyseniz aynı sekmede yazan Webhook adresini sağlayıcının kendi paneline kopyalayın. O olmadan hiçbir şey tamamlanmaz.
Taksit ve Komisyon sekmesinde taksit oranlarınızı yazın.
Yayına almadan önce bankanızın test bilgileriyle deneyin.

Ücretsiz eklenti veritabanı tablosu oluşturmuyor ve zamanlanmış iş kaydetmiyor. Her şey WordPress seçeneklerinde ve sipariş meta verisinde duruyor.

Pro ayrı bir eklentidir; ücretsiz sürümün yerine değil, yanına kurulur. Ücretsiz sürüm WordPress.org'a gidiyor ve orada yayımlanan her şey GPL altında dağıtılabiliyor; Pro kaynağı aynı pakette olsaydı lisans kapılarını silen herkes onu yasal olarak dağıtabilirdi. Lisans anahtarı Lisans sekmesine girilir.

WooCommerce → Ayarlar → Ödemeler → MevvPos ekranı sizi MevvPos sayfasına yönlendirir. Bu bilinçlidir: bu ayarların tek bir yeri olmalı, birbirine ters düşebilecek iki yeri değil.

Nasıl çalışır

MevvPos iki tür ödeme protokolü konuşuyor ve hangisiyle karşılaşacağınız seçtiğiniz sağlayıcıdan çıkıyor. İkisi de aynı motordan geçiyor ve aynı sipariş kaydını üretiyor.

İmzalı form — Türkiye: Yedi Türk sanal POS ailesi. MevvPos ödeme alanlarını kuruyor, mağaza anahtarınızla imzalıyor ve bankaya POST ediyor. Müşteri 3-D Secure ile doğrulanıyor ve banka sitenize dönüyor; siparişi tamamlayan şey o dönüşteki imza.
Barındırılan sayfa ve webhook — uluslararası: Stripe, PayPal, Mollie, Square, Authorize.Net, Checkout.com, Razorpay ve Paystack. MevvPos ödemeyi sağlayıcıda kendi REST API'si üzerinden oluşturuyor ve müşteriyi sağlayıcının kendi sayfasına gönderiyor. Siparişi tamamlayan şey sağlayıcıdan gelen bir yanıt: webhook adresinize ulaşan imzalı bildirim ya da — müşteri o gelmeden geri dönerse — dönüş sayfasından yapılan sunucudan sunucuya durum sorgusu. Bir siparişi tek başına asla tamamlamayan şey ise tarayıcının dönüşü.

Türkiye tarafında motor, uluslararası sağlayıcıların hiç ihtiyaç duymadığı bir şey yapıyor: kartı hesaplarınızdan hangisinin alacağına karar veriyor.

Bir ya da birden fazla POS kaydı tanımlarsınız. Bir POS kaydı bir bankanın sanal POS'udur: kimlik bilgileri, geçit adresi, taksit oranları.
Müşteri ödeme adımında kartını yazar. İlk altı hane — BIN — kartı çıkaran bankayı belirtir.
MevvPos BIN'i arar ve ödemeyi o bankadaki sizin POS'unuza gönderir; öyle bir POS'unuz yoksa varsayılan POS'a düşer.
Taksit yalnız kart o POS'un kendi bankasının kartıysa gösterilir; bankalar başka bankanın kartına taksit yaptırmıyor.
Müşteri bankada 3D Secure adımından geçer, banka sitenizdeki tek bir geri dönüş adresine döner.
Geri dönüşteki imza, siparişin gerçekten kullandığı POS'un anahtarıyla doğrulanır; sipariş tamamlanır ve sonuç kaydedilir.

Kart numarası, son kullanma tarihi ve güvenlik kodu veritabanınıza ve WooCommerce oturumuna hiç yazılmaz. Saklanan tek kart verisi ilk altı hane ve tanınan banka adıdır.

Uluslararası sağlayıcılarda sitenize hiç kart verisi ulaşmıyor: kart sağlayıcının kendi sayfasında yazılıyor. Onları küçük bir PCI kapsamına giden en kısa yol yapan şey bu — ve aynı zamanda neden BIN yönlendirmesi ile taksit taşımadıklarının da cevabı.

Uluslararası sağlayıcılar

Uluslararası sağlayıcılar Türkiye dışındaki dünyayı kapsıyor. Hepsi sağlayıcının kendi barındırdığı ya da yönlendirdiği sayfayı kullanıyor, yani kart bilgisi sitenizde hiç yazılmıyor. Kimlik doğrulama da orada yürüyor, ama sonucu orada bırakmıyoruz: MevvPos ödeyenin doğrulanıp doğrulanmadığını kaydediyor, banka ek doğrulama istediğinde müşteriyi bankaya gönderiyor ve ters ibraz sorumluluğunun devredilip devredilmediğini ECI’den okuyup yazıyor. Sağlayıcı sonucu bildirmiyorsa bu, size aitmiş gibi değil, bilinmiyor olarak kaydediliyor. Kartın ötesinde yerel yöntemler her sağlayıcının kendi alanıyla gidiyor: iDEAL, Bancontact, SEPA doğrudan borçlandırma, Klarna, EPS, Przelewy24, BLIK, TWINT, Multibanco ve cüzdanlar. Bir hesabın hangilerini sunacağını siz seçersiniz; seçmediğiniz bir yöntem hiç gönderilmez. Para birimi siparişe uymayan yöntem doğrudan düşürülür — dolarlı bir siparişte iDEAL sunmak yalnız ödemenin sağlayıcıda başarısız olmasına yol açardı.

Stripe: mode=payment ile bir Checkout Session; bu, Stripe'ın kendi sayfasının arkasında bir Payment Intent yaratıyor. Gizli anahtar üye işyeri anahtarına, Webhook signing secret ise ek alana giriyor. Siparişi imzası doğrulanmış bir payment_intent.succeeded tamamlıyor. Elements bilerek kullanılmıyor: kullanmak kart alanlarını sizin sayfanıza taşır ve PCI kapsamınızı büyütürdü.
PayPal: Orders v2, üç adımda: siparişi yarat, müşteri PayPal'da onaylasın, MevvPos tahsil etsin. Gözden kaçması en kolay olan üçüncü adım — onaylanmış ama hiç tahsil edilmemiş bir sipariş, ödenmiş görünürken parayı hesaba geçirmez. REST istemci kimliği üye işyeri numarasına, istemci sırrı üye işyeri anahtarına, Webhook ID ise ek alana giriyor.
Mollie: Payments API v2. API anahtarı — live_… ya da test_… — üye işyeri anahtarına giriyor ve ek alan yok, çünkü Mollie bildirimlerini imzalamıyor. MevvPos'un bunun yerine ne yaptığı için aşağıdaki webhook bölümüne bakın.
Square: Checkout API üzerinden bir Payment Link. Erişim jetonunu üye işyeri anahtarı olarak, ayrıca Location ID ve Webhook signature key girin. Square her satışı bir konuma bağlıyor: Location ID olmadan ödeme hiç yaratılamıyor ve Square'in kendi hatası bunu açıkça söylemiyor.
Authorize.Net: Accept Hosted. API Login ID üye işyeri numarasına, Transaction Key üye işyeri anahtarına, Signature key ise ek alana giriyor — Transaction Key'den ayrı bir değer ve karıştırılması kolay. Yönlendirme adresi vermeyen tek sağlayıcı bu: bir jeton dönüyor ve MevvPos o jetonu barındırılan sayfaya form olarak POST ediyor.
Checkout.com: Barındırılan Ödeme Sayfası. Gizli anahtar (sk_…) mağaza anahtarına, webhook imza anahtarı ek alana giriyor; bildirim ham gövde üzerinden HMAC-SHA256 ile imzalanıyor. Hesaba katılması gereken bir davranış var: iade eşzamansız kabul ediliyor. Checkout.com iade çağrısına 202 ve bir eylem kimliğiyle yanıt veriyor; bu, isteğin alındığı anlamına geliyor — paranın geri gittiği değil.
Razorpay: Hindistan'a satış yapan mağazalar için bir Ödeme Bağlantısı: orada kart tek başına yetmiyor, UPI, internet bankacılığı ve cüzdanlar sağlayıcının sayfasında toplanıyor. Key ID üye işyeri numarasına, Key Secret mağaza anahtarına, webhook sırrı — Key Secret'tan ayrı bir değer — ek alana giriyor. Razorpay iki kimlik döndürüyor ve bunlar birbirinin yerine geçmiyor: durum, bağlantı kimliğiyle (plink_…) soruluyor; iade ise yalnız bağlantının ödendikten sonra bildirdiği ödeme kimliğiyle (pay_…) yapılabiliyor.
Paystack: Nijerya, Gana, Güney Afrika, Kenya ve Fildişi Sahili'ne satış yapan mağazalar için barındırılan bir işlem sayfası; oralarda USSD, banka havalesi ve mobil para en az kart kadar önemli. Gizli anahtar (sk_live_… ya da sk_test_…) mağaza anahtarına giriyor ve ek alan yok — bildirim aynı gizli anahtarla HMAC-SHA512 kullanılarak imzalanıyor. Her şey tek bir referansa asılı: ödemeyi başlatmak, durumunu sormak ve iade etmek hepsi onu kullanıyor.

Test kipi PayPal, Square ve Authorize.Net'te sağlayıcının kendi kum havuzu adresini devreye alıyor. Stripe ile Mollie canlıyı testten adresle değil anahtarla ayırıyor; orada yapıştırdığınız anahtar belirliyor.

Tutarlar uçtan uca para biriminin alt biriminde tam sayı olarak taşınıyor — kuruş, sent — hiçbir yerde ondalık kesir olarak değil. Geri ondalıklı bir dize isteyen tek sağlayıcı Mollie ve hane sayısının para birimine göre tam doğru olmasını istiyor: 10.0 reddedilirken 10.00 kabul ediliyor. O dize tam sayıdan üretiliyor, kayan noktadan değil.

Sekizinin hiçbiri gerçek bir üye işyeri hesabıyla uçtan uca doğrulanmadı. Her sağlayıcı dosyası bunu kendi başlığında yazıyor ve hangi belge sayfalarından yazıldığını sayıyor. Akışlar sağlayıcıların yayımlanmış belgelerini izliyor, imza algoritmaları ve alan adları da oraya sabitlenmiş durumda; ama bu, tamamlanmış canlı bir ödemeyle aynı şey değil ve öyleymiş gibi anlatmayacağız. Bunları üretimde kanıtlanmış değil, kendi kum havuzunuza bağlanmaya ve denenmeye hazır diye okuyun.

POS kayıtları

POS çubuğu sekmelerin üstündedir ve her sekmede görünür. Her kart bankayı, mağaza numarasını ve gerektiğinde bir rozet gösterir.

Varsayılan: Daha iyi bir eşleşme bulunmadığında tahsilatı yapan POS. Her zaman tam olarak bir tane vardır.
Pasif: Duruyor ama tahsilat yapmıyor. Bankada henüz açılmamış bir POS'u silmek yerine pasife alın — aksi hâlde o bankanın kartını taşıyan gerçek bir müşteri ödeme yapamaz.
Lisans bekliyor: Kayıt duruyor ama lisans etkin olmadığı için beklemede. Hiçbir şey silinmedi; lisans yenilenince kaldığı yerden devam eder.
API bilgileri girilmedi: Kaydın henüz mağaza numarası yok.

Bankalar logoyla değil renk şeridiyle gösterilir. Banka logoları tescilli markadır; on beş tanesini taşımak hem hukuki risk hem sürekli bakım demek — üstelik kendi bankanızı zaten biliyorsunuz.

Son POS silinemez, son etkin POS kapatılamaz. Kart ödemesini tamamen durdurmak için Genel sekmesinden ödeme yöntemini pasife alın.

Sağlayıcı hesabı sayısında sınır yok ve aralarındaki yönlendirme — kartı çıkaran bankaya ve siparişin para birimine göre — ücretsiz eklentinin parçası. Önceki sürümler tek hesaba izin veriyordu; o sınır 4.9.0'da kaldırıldı.

Lisans dolduğunda tahsilata devam eden hesap rastgele seçilmiyor: varsa varsayılan işaretli olan, yoksa yapılandırılmış ilk etkin hesap. Rastgele seçmek, mağazanın bir sabah sessizce başka bir bankadan tahsilat yapmaya başlaması demek olurdu.

Banka API — kimlik bilgileri ve geçit adresi

Sağlayıcı: Liste iki grup hâlinde geliyor: Türkiye — banka sanal POS ve Uluslararası ödeme sağlayıcıları. Formun size sorduğu her şey bu tek seçimden çıkıyor ve seçiminize uygulanamayacak ayarlar hiç gösterilmiyor.
Banka: POS'u aldığınız banka. Geçit adresi ve taksit için kullanılan BIN listesi bu seçime göre gelir. Henüz karşılığı yazılmamış kurumlar "— yakında" ile listelenir ve seçilemez.
Mağaza No (Client ID): Bankanın verdiği mağaza numarası.
İşyeri Anahtarı (Store Key): İşyeri güvenlik anahtarı. Parola alanı olarak tutulur; kaydedildikten sonra maskeli gösterilir.
Gate URL: Ödeme formunun POST edileceği adres.
Siparişin kendi para birimini bankaya gönder: Yalnız Türk sanal POS'larında ve varsayılan olarak kapalı: MevvPos Türk lirası gönderiyor, çok para birimli bir anlaşmanız yoksa bankanızın beklediği de bu. Para birimi imzanın parçası, dolayısıyla bankanızın kabul etmediği bir değer açıklamasız reddediliyor. Uluslararası sağlayıcılar siparişin para birimini olduğu gibi alıyor ve onlara bu soru hiç sorulmuyor.
Test modunu aktif et: Otomatik yönlendirmeyi durdurur; isteği gönderilmeden önce inceleyebilirsiniz.

Kaydederken İşyeri Anahtarı'nı boş bırakmak "değiştirme" demektir. Boş değeri yazmak anahtarı silerdi ve mağazanız tek bir hata mesajı vermeden ödeme almayı bırakırdı. Aynı kural diğer gizli alanlar için de geçerlidir.

Bazı aileler ek kimlik bilgisi istiyor ve form bunları yalnız seçtiğiniz sağlayıcı için gösteriyor:

Garanti BBVA — Üye İşyeri No (MerchantId), Provizyon Kullanıcı Adı, Provizyon Parolası.
VakıfBank — Terminal No ve MPI adresi (boş bırakırsanız test adresi kullanılır).
PayTR — Merchant Salt.
iyzico, Craftgate, Sipay — ek alan yok: API anahtarı Mağaza No'ya, gizli anahtar İşyeri Anahtarı'na girilir.
Stripe — Webhook signing secret.
PayPal — Webhook ID.
Square — Location ID ve Webhook signature key.
Authorize.Net — yalnız webhook için kullanılan Signature key.
Mollie — ek alan yok: API anahtarı Üye işyeri anahtarına giriyor.

Bu ek kimlikler imzaya girer. Biri eksikse imza boş değerle üretilir ve banka ödemeyi sessizce reddeder — hata yok, mesaj yok, yalnız ret.

Yedi NestPay bankası için geçit adresi banka seçiminizden gelir; Gate URL'i boş bırakabilirsiniz. Diğerlerinde alan hazır gelmez: bankanızın ya da kuruluşun verdiği adresi yazın, yoksa ödeme formunun gideceği bir yer olmaz.

Desteklenen on üç kurum

NestPay / Asseco (Payten): İş Bankası, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat Bankası
Garanti GT3D: Garanti BBVA
PayFlex V4: VakıfBank
Ödeme kuruluşları: iyzico, PayTR, Craftgate, Sipay

Karşılığı yazılmamış kurumlar banka listesinde bilerek duruyor, "— yakında" ile işaretli. Listeden çıkarmak hangi protokol ailelerinin eksik olduğunu görünmez yapardı. Sizinki onlardan biriyse Banka Talebi sekmesi bunu söyleyeceğiniz yer.

Yalnız NestPay imzasının, bankanın kendi yayımladığı örneğe karşı altın değerli bir testi var. Diğer her sağlayıcı kendi kaynağında beta işaretli: akış dokümana göre yazıldı ama o kurumda gerçek bir üye işyeri hesabıyla uçtan uca doğrulanmadı. Doğrulanana kadar bu etiket kalır.

Ödeme kuruluşları kart ihraç etmediği için BIN listeleri yoktur. Onlara yönlendirilmez, onları POS olarak seçersiniz.

Webhook'lar — siparişin asıl tamamlandığı yer

Her uluslararası sağlayıcı sitenizde tek bir adres istiyor ve adresin biçimi hepsinde aynı: ana adresinizin üzerinde ?mevvpos-webhook=<saglayici>. Tam değeri Bank API sekmesinde salt okunur olarak yazıyor; alana tıklamak onu seçiyor.

Siparişi tamamlayan şey webhook'tur, müşterinin sitenize dönmesi değil. Dönüş adresi tahmin edilebilir ve müşteri oraya hiç ödeme yapmadan da ulaşabilir; oraya gelen bir tarayıcı tek başına hiçbir şeyi kanıtlamaz. MevvPos sonucu dönüşten hiç okumuyor: ya imzalı bildirimi bekliyor ya da sağlayıcıya sunucudan sunucuya doğrudan soruyor. Bu iki cevaptan biri gelene kadar sipariş beklemede kalıyor ve sipariş notu bunu yazıyor.

Adresi Bank API sekmesinden kopyalayın.
Mollie istisna ve hiçbir yere bir şey yapıştırmayı gerektirmiyor: MevvPos adresi yarattığı her ödemeyle birlikte gönderiyor. Site yerel bir adreste cevap veriyorsa adres hiç gönderilmiyor, çünkü Mollie zaten oraya ulaşamazdı — yerel geliştirmede sonuç bunun yerine durum sorgusundan geliyor.
Sağlayıcının kendi paneline göründüğü gibi birebir yapıştırın. Square imzasını bildirim adresiyle gövdeyi birlikte alarak hesaplıyor; tek karakterlik bir fark — sondaki bir eğik çizgi yeter — bütün olayları sessizce doğrulamadan düşürür.
Sağlayıcının geri verdiği imza sırrını o sağlayıcının ek alanına kaydedin.
Sağlayıcının panelinden bir test olayı gönderin ve bir siparişin gerçekten hareket ettiğini görün.

Mollie bildirimini hiç imzalamıyor — gövdede bir ödeme kimliğinden başka bir şey yok. Bu güvensiz görünüyor ama aslında daha güvenli: MevvPos bildirime güvenmiyor, onu bir kapı zili sayıyor. Kimliği alıp ödemenin durumunu doğrudan Mollie'ye soruyor ve yalnız paid cevabı bir olay üretiyor. Saldırgan uydurma bir kimlikle zili çalabilir ama Mollie'nin cevabını üretemez; dolayısıyla sahte bir bildirim hiçbir siparişi ödendi yapamaz. Mollie'ye ulaşılamıyorsa cevap “bilmiyorum” olur ve hiçbir şey değişmez.

PayPal'ın imzası da yerelde doğrulanmıyor. O bir sertifika zinciri ve zincir doğrulamasında yapılacak sessiz bir hata imzayı tümüyle anlamsız kılar; PayPal bunun için bir uç nokta yayımlıyor ve SUCCESS dışında her cevap olayın yok sayılması demek.

Her sağlayıcı için üç kural geçerli. Cevap her zaman boş bir 200 — doğrulanmış olay da, yinelenen olay da, çöp de aynı cevabı alıyor; farklı cevap vermek saldırgana hangi denemesinin daha yakın olduğunu söylerdi, hata cevabı vermek ise sağlayıcıyı asla doğrulanamayacak bir olayı yeniden denemeye iterdi. Tek istisna PayTR: gövdede harfiyen OK görmek istiyor ve görmezse bildirimi saatlerce tekrarlıyor. Aynı olayın iki kez gelmesinin ikinci bir etkisi yok. Bir olayın hangi hesaba karşı doğrulanacağı ise istekten değil kendi yapılandırmanızdan okunuyor — yoksa saldırgan kendi sahteciliğinin hangi anahtarla kontrol edileceğini kendisi belirlerdi.

Webhook WooCommerce'in uç noktasından geçmiyor. Kendi sorgu değişkeni var ve tema, sayfa ve sorgu makinesi hiç çalışmadan yakalanıyor — WooCommerce kurulu olmayan bir sitede de çalışmasının sebebi bu.

BIN bazlı yönlendirme

Kartın ilk altı hanesi onu çıkaran bankayı belirtir. MevvPos tam olarak o altı haneye bakar.

BIN tablosunun bir anlık görüntüsü eklentinin içinde geliyor — bu derlemede 36 bankaya yayılmış 1.449 BIN — böylece yönlendirme çevrimdışı, hiçbir hesap gerekmeden, kurduğunuz andan itibaren çalışıyor.
Pro bunu haftada bir sunucularımızdan tazeler. Tazeleme paketteki tablonun üzerine eklenir, onu değiştirmez: eksik ya da boş bir yanıt hiçbir mağazayı BIN'siz bırakmamalı.
Yüz BIN'den az taşıyan bir yanıt inandırıcı bulunmaz ve yazılmaz.
Çakışmalar — aynı BIN'i iki bankanın birden sahiplenmesi — liste gönderilmeden önce bizim tarafımızda çözülür. Yerelde çözen bir mağaza kartı hem "bizim" sayar hem başka bankaya yönlendirirdi.

Tanınmayan BIN asla reddedilmez. Varsayılan POS'a düşer. Elimizde kaydı olmayan bir kartı geri çevirmek, bir arama tablosunu korumak için satış kaybetmek olurdu.

Aynı tablo ödeme adımında ikinci ve farklı bir soruyu da cevaplar: bu kart bu POS'un kendi bankasının mı? Taksit gösterilip gösterilmeyeceğine bunu karar verir — aşağıya bakın.

BIN doğruluğu ücretli bir özellik değildir. Pro'nun karşılığı güncellik, doğruluk değil: paketteki liste aynı listedir, yalnız derleme anında dondurulmuştur.

Taksit ve komisyon

Oranlar POS başına, tek çekimden on iki taksite kadar, Taksit ve Komisyon sekmesinde girilir. Yüzde olarak yazılır: %5,5 için 5.50.

Bu, iki ödeme yüzeyinde de çalışıyor. Blok sayfasında taksit tablosunu bloğun kendisi çiziyor ve komisyon sepete bir ücret olarak ekleniyor — tıpkı klasik sayfadaki gibi. Yani bir taksit seçmek, sipariş verilmeden önce toplamı güncelliyor.

Taksit Türkiye'ye özgü bir kurum ve sekme bunu biliyor. Uluslararası bir sağlayıcı seçiliyken oran tablosu hiç gösterilmiyor, sekme bunun yerine bir cümleyle durumu açıklıyor: asla uygulanamayacak on iki satırı doldurtmak sizi yanıltmanın bir yolu olurdu.

0: Seçenek gösterilir, komisyon alınmaz.
Boş: Seçenek hiç gösterilmez. Boş ile sıfır aynı şey değildir.

Komisyon sepete "N Taksit Komisyonu" adıyla, vergiye tabi bir ücret olarak eklenir ve kargo ile vergi dahil sepet tutarı üzerinden hesaplanır.

Taksit yalnız o POS'un kendi bankasının kartlarında gösterilir ve bu sunucu tarafında zorlanır — arayüzde gizlemek yetmez. Başka bankanın kartı tek çekime döndürülür ve ücret temizlenir.

Tavan her kurulumda on iki — bu bankaların kendi uyguladığı sınır, bir ürün sınırı değil. Üç yerde birden uygulanıyor: müşterinin gördüğü liste, formla gelen değer ve motorun sağlayıcıya gönderdiği değer. Değiştirilmiş bir form, sunduğunuzdan fazla taksit satın alamıyor.

Ayar formu lisansınız ne olursa olsun on iki alanın hepsini gösterir. Lisans bitince alanlar kaybolsaydı, sayfayı kaydetmek daha önce girdiğiniz oranları sessizce silerdi. Tavanınızın üstündeki alanlar "Pro'da açılır" diye işaretlenir ve yazdığınız sayılar korunur.

Bankadan gelen bir taksit tablosu yoktur. Oranlar sizin girdiklerinizdir; geçmiş bir siparişin komisyonu satışın yapıldığı gün geçerli olan orandan hesaplanır — bugün oranı değiştirmek dünkü raporu yeniden yazmaz.

Ödeme akışı ve kart

Her Türk ailesi 3-D Secure’dan geçiyor. 3D’siz kip yok, kapatan bir ayar da yok. Uluslararası tarafta MevvPos EMV 3-D Secure 2 konuşuyor: ödeyenin ek doğrulamayla mı doğrulamasız mı kimliklendirildiğini kaydediyor, banka ek doğrulama istediğinde müşteriyi bankaya gönderiyor ve ters ibraz sorumluluğunun devredilip devredilmediğini ECI’den okuyup yazıyor. Bilerek yapmadığı iki şey var: sağlayıcının alanı olmayan bir muafiyeti asla talep etmiyor ve sağlayıcı sonucu bildirmediğinde sorumluluğu size aitmiş gibi yazmıyor — “bilmiyoruz” ile “sorumluluk satıcıda” aynı cevap değildir.

Form akışı: NestPay, Garanti, PayTR ve Sipay: tarayıcı imzalı formu bankaya gönderir, müşteri doğrulamasını yapar, banka sitenize döner.
Sunucu akışı: VakıfBank, iyzico ve Craftgate: sunucunuz kuruluşla konuşur, 3D sayfasını alır, gösterir ve doğrulamadan sonra satışı sunucudan sunucuya tamamlar.
Yönlendirme akışı: Stripe, PayPal, Mollie, Square, Checkout.com, Razorpay ve Paystack: MevvPos ödemeyi sağlayıcının REST API'si üzerinden oluşturuyor ve müşteriyi sağlayıcının döndürdüğü adrese gönderiyor.
Jetonlu form akışı: Authorize.Net: sağlayıcı adres yerine bir jeton döndürüyor ve jeton barındırılan sayfaya form olarak POST ediliyor. Jetonu adrese yazmak onu tarayıcı geçmişine ve sunucu kayıtlarına sızdırırdı.

Türk bankaları her zaman sitenizdeki tek bir adrese dönüyor: ?wc-api=mevvpos_callback. O dönüşteki imza, siparişin gerçekte kullandığı POS'un anahtarıyla doğrulanıyor; anahtar siparişin kendisine kaydediliyor — birden çok POS varken yanlış anahtarla doğrulamak her ödemede hash hatası üretir.

Kart veritabanınıza hiç ulaşmaz. Yönlendirme süresince tarayıcıda tutulur ve sonra silinir. Ödeme sayfası açıldığında kart orada değilse — yeni sekme, sayfa yenileme, kapalı depolama, bankadan geri tuşuyla dönüş — bankaya boş alan göndermek yerine görünür bir kart formu çıkar. Kart formu bilerek varsayılan olarak görünürdür: ödeme akışının çalışması JavaScript'in çalışmış olmasına bağlı olamaz.

Banka ödemeyi onayladıysa, 3D durum kodu beklenmedik olsa bile sipariş tamamlanır; bir sipariş notu durumu kaydeder ve işlemi bankanın kendi ekranından teyit etmenizi ister. Banka "onaylandı" dediyse müşterinin kartı çekilmiştir; bunu reddetmek "kartınız çekildi ama siparişiniz olmadı" demek olurdu.

Her deneme; kullanılan POS'u, kartın bankasını ve BIN'ini, taksit sayısı ile oranını, sonucu, bankanın yanıt kodu ve mesajını, provizyon ve işlem referanslarını kaydeder.

Ön provizyon, ödeme linkleri ve risk kuralları

Şimdi provizyon, sonra tahsilat

Her POS kaydı bir tahsilat yöntemi taşır: doğrudan çek ya da tutarı bloke edip sonra tahsil et. İkincisinde para ödeme anında kartta rezerve edilir ve sipariş ekranına iki düğme gelir — tahsil et (tamamı ya da bir kısmı) ve serbest bırak. Kargo çıkarken tahsil edin; tedarik edemiyorsanız serbest bırakın.

Ayar yalnız sağlayıcının gerçekten taşıdığı yerde görünür: NestPay banka ailesi (İşbank, Akbank, Halkbank, QNB, Şekerbank, TEB, Ziraat) ile Stripe, Authorize.Net ve Checkout.com. Diğer sağlayıcılarda seçenek hiç sunulmaz — sunulup sonra geçitte hata vermesindense.

Bir ödeme linki

Ödeme linkleri ekranı bir tutar için, isterseniz bir açıklama ve son kullanma tarihiyle link üretir. Linki açan kişi, kendisi için açılmış bekleyen bir siparişle mağazanın sıradan ödeme sayfasına düşer; yani aynı BIN yönlendirmesi, aynı taksit tablosu ve aynı 3D Secure adımı geçerlidir. Hiçbir şey ödeme motorunun etrafından dolaşmaz.

Jeton 32 rastgele bayttır; bir adresten diğeri tahmin edilemez.
Link belirlediğiniz tarihte geçerliliğini yitirir.
Bir kez çalışır. Sipariş ödendikten sonra link açılmayı bırakır, böylece iletilmiş bir mesajla ikinci kez ödeme yapılamaz.

Risk kuralları

Risk ekranı beş kural taşır; her biri ayrı açılır ve kendi eşiğini alır. Kart herhangi bir sağlayıcıya gönderilmeden önce değerlendirilirler ve her biri siparişi işaretleyebilir, incelemeye alabilir ya da doğrudan reddedebilir.

Adres başına deneme — bir ziyaretçinin bir zaman aralığında kaç ödeme denemesi yapabileceği.
Kart başına deneme — aynı sayının tek bir kart için karşılığı.
Art arda başarısızlık — üst üste gelen ret dizisi.
Ülke uyuşmazlığı — fatura adresi Türkiye dışında olan, Türkiye'de çıkarılmış bir kart.
Tutar tavanı — üzerinde önce bakmak isteyeceğiniz sipariş toplamı.

Hiçbir adres ve hiçbir kart numarası yazılmıyor. Sayaçların tuttuğu şey kendi site anahtarınızla tuzlanmış bir özet; kurallar tekrarı böyle tanıyor ve ekran hiçbir zaman ikinci bir kart veritabanına dönüşmüyor. Cihaz parmak izi yok, makine öğrenmesiyle üretilmiş bir skor yok, BIN kara listesi yok — okuyabileceğiniz beş kural ve müşteriye açıklayamayacağınız hiçbir şey yok.

İadeler

Uluslararası sağlayıcılarda iade, WooCommerce sipariş ekranından her zamanki gibi yapılıyor — tamamı ya da bir bölümü. MevvPos iadeyi siparişe kaydedilmiş ödeme referansı üzerinden sağlayıcıya gönderiyor.

İade hiçbir zaman lisansa bağlanmıyor. Müşteriye parasını geri verememek bir yenileme hatırlatmasının yol açmasına izin verilecek bir şey değil, üstelik çoğu ülkede yasal bir yükümlülük.

Türk banka sanal POS'ları henüz WordPress'ten iade edilemiyor ve MevvPos bunu numara yapmak yerine açıkça söylüyor. İşlemi bankanızın kendi ekranından iade edin. Sessizce başarı bildirmek, para bankada dururken WooCommerce'in siparişi iade edildi diye işaretlemesine yol açardı — yanlış bir muhasebe kaydı, çalışmayan bir düğmeden çok daha pahalıdır.

İade, sağlayıcının geri verdiği ödeme referansını gerektiriyor. O referans kaydedilmeden önce verilmiş bir sipariş ya da sağlayıcı hesabı sonradan silinmiş bir sipariş eklenti üzerinden iade edilemez.

Raporlar

Raporlar sekmesi ciroyu, başarılı işlem sayısını, başarı oranını ve tek çekim / taksitli dağılımını günlük grafikle gösterir. Bankadan dönüş bekleyen işlemler ayrı sayılır ve başarı oranına dahil edilmez.

Ciro özeti her kurulumda 7, 30 ya da 90 günü kapsıyor. Pro ek eklentisi bunun üstüne üç kırılım ekliyor:

Taksit ve komisyon yükü — her taksit kademesinin adedi, cirosu ve komisyon yükü.
POS ve banka kırılımı — her POS ve kartın her bankası için ciro, başarılı, başarısız ve başarı oranı.
Red kodu dağılımı — CSV dışa aktarmayla birlikte. Tekrar eden bir red kodu çözülebilir bir şeyi gösterir: yetersiz bakiye müşteri kaynaklıdır, ama 3D doğrulama ve POS yapılandırma hataları sizde çözülür.

Raporların dayandığı veriyi ücretsiz eklenti toplar; Pro'nuz olsun olmasın geçmiş birikmeye devam eder. Böyle olmak zorunda: yükseltince geriye dönük veri üretilemez.

Yeni kurulmuş bir mağazada grafik boştur. Kayıt eklentiyle başlar; ekran ilk ödeme denemesinden sonra dolar.

Motoru WooCommerce olmadan kullanmak

WooCommerce geçidi artık motorun kendisi değil, ödeme motorunun bir tüketicisi. Motor sipariş, sepet ya da oturum diye bir şey bilmiyor: ona bir ödeme niyeti veriyorsunuz — alt birimde tam sayı bir tutar, bir para birimi, bir referans ve dönüş adresleri — o da size ya POST edilecek bir form ya da yönlendirilecek bir adres veriyor. Bir form eklentisi, bir randevu eklentisi ya da kendi kodunuz motoru ödeme sayfasıyla aynı biçimde sürebiliyor.

MevvPos_Payment_Engine::start() ödemeyi başlatıyor ve tarayıcının bundan sonra ne yapacağını döndürüyor.
MevvPos_Payment_Engine::handle_webhook() bir ödemenin durumunu değiştiren tek yol. İmzası doğrulanmayan olay hiçbir şeyi değiştirmiyor ve kayda geçiyor.
MevvPos_Payment_Engine::webhook_url() sağlayıcının paneline yapıştırdığınız adresi kuruyor.
Taksit tavanı son savunma hattı olarak motorun içinde de uygulanıyor — çağıran ekran, lisans dolmadan önce basılmış olabilir.

4.0.0'dan önce mevvpos_providers süzgeciyle kendi sağlayıcınızı kaydettiyseniz, artık WC_Order yerine bir ödeme niyeti alıyor. Yedi Türk ailesinin istekleri ve imzaları değişmedi, yani mevcut POS kurulumları hiç dokunulmadan çalışmaya devam ediyor.

Banka talebi ve destek

Banka Talebi: Henüz yazılmamış her kurumu gerekçesiyle listeler: ya protokol ailesi belirlenmemiştir, ya aile bilinir ve doküman beklenmektedir. Bunlardan biri için talep açabilir ya da listede hiç olmayan bir kurumu yazabilirsiniz.
Destek: Konu, ilgili POS ya da banka, ne yaptığınızda ne olduğu ve bankanın gösterdiği hata mesajı.

Destek formu kart numaranızı ve güvenlik kodunuzu yazmamanızı ister. Bir ödeme sorununu teşhis etmek için hiçbir zaman gerekmezler ve iki formda da ödeme ya da kart verisi gönderilmez.

Ücretsiz eklenti sunucularımıza yalnız siz bu düğmelere bastığınızda ulaşır. Zamanlanmış hiçbir gönderim yoktur ve ücretsiz sürümde lisans çağrısı hiç yapılmaz.

Ücretsiz ve Pro

Ücretsiz eklentide kilitli, sınırlı ya da sayılan hiçbir şey yok. Bütün Türk kurumları, bütün uluslararası sağlayıcılar, 3D Secure, barındırılan sayfa ödemesi, cüzdanlar, çoklu para birimi, para birimi ve BIN yönlendirmesi, kaç üye işyeri sözleşmeniz varsa o kadar POS hesabı, on ikiye kadar taksit, test kipi, iadeler, ön provizyon, ödeme bağlantıları, risk kuralları ve 7 / 30 / 90 günlük ciro raporu — hepsi anahtarsız ve hesapsız çalışıyor. Pro ayrı bir eklenti ve kodu ücretsiz pakette hiç bulunmuyor; bir tavanı yükseltmiyor, yetenek ekliyor.

Ücretsiz: Aksi yazmadıkça bu sayfadaki her şey: sınırsız sağlayıcı ve POS hesabı, BIN ve para birimi yönlendirmesiyle birlikte, on ikiye kadar taksit, 7 / 30 / 90 günlük ciro raporu, pakette gelen BIN tablosu, ön provizyon, ödeme bağlantıları, risk kuralları, iadeler ve sınırsız işlem hacmi. Apple Pay ve Google Pay de dahil, çünkü sağlayıcının barındırdığı sayfada kendiliğinden çıkıyorlar.
Pro: Tekrarlayan ödemeler ve abonelik faturalaması, yetki deposu, Hesabım ekranındaki saklı ödeme yetkileri, SCA muafiyet talepleri, POS / banka / taksit / ret kodu kırılımları ve CSV dışa aktarma, haftalık canlı BIN tazelemesi. Ayrı bir eklenti; buradaki hesabınızdan iniyor, WordPress.org'da bulunmuyor.

Çoklu para birimi de, para birimine göre yönlendirme de ücretsiz. Kısa bir süre Pro ile satıldılar; euro siparişini euro hesabına yöneltebilmek için para almak, bir yeteneği değil bir kısıtı fiyatlandırmaktı ve kaldırıldı.

Lisans bittiğinde ya da hiç yokken:

Ücretsiz eklentide hiçbir şey değişmiyor. O paket lisans diye bir şey sormuyor — soru 4.9.1'de paketten çıkarıldı — yani her hesap, her taksit planı, her yönlendirme ve raporun tamamı aynen çalışmaya devam ediyor.
Mağazanız ödeme almaya devam ediyor. Ödeme yolunun hiçbir yerinde lisans kontrolü yok. Bir dükkânın cirosunu kesmek, yenileme hatırlatması göndermenin kabul edilebilir bir yolu değil.
İadeler çalışmaya devam eder, çünkü hiç kapıya bağlı değiller.
Zamanlanmış tekrarlayan çekimler alınmaz olur ve abonelik ekranları susar. Yetkiler ve saklı ödeme izinleri hiçbir zaman silinmiyor; yenilemede kaldıkları yerden devam ediyorlar.
Kırılımlar ve CSV dışa aktarma durur. Altlarındaki 7 / 30 / 90 günlük rapor ücretsiz eklentide ve kalır. Toplanmış geçmiş silinmiyor.
Canlı BIN tazelemesi durur; paketteki tablo çalışmaya devam eder.

Sunucularımıza ulaşılamıyorsa, etkin bir lisans son başarılı doğrulamaya dayanarak yedi gün daha açık kalır. Ama kendi bitiş tarihi geçmiş bir lisans buna bakmadan süresi dolmuş sayılır — aksi hâlde adresimizi engellemek, lisansı bir hafta uzatmanın yolu olurdu.

Güncellemeler

Pro eklentisi lisansınıza bağlı bir güncelleyici taşıyor. Taşımak zorunda: Pro WordPress.org'da yayımlanmıyor, dolayısıyla WordPress'in yeni bir sürümün varlığını öğrenebileceği bir yer yok. Lisans etkinken Pro güncellemesi eklentiler ekranında diğerleri gibi görünüyor.

Ücretsiz eklenti artık kendi güncellemesini de duyuruyor. Sunucumuza daha yeni bir sürüm olup olmadığını soruyor ve yanıtı WordPress'in kendi güncelleme akışına veriyor; böylece yeni sürüm, birinin elle zip indirmesini beklemek yerine eklentiler ekranında sıradan bir Güncelle düğmesiyle beliriyor. İstek yalnız paket adını ve kurulu sürümü taşıyor — site adresi yok, e-posta adresi yok, lisans anahtarı yok, eklenti envanteri yok. İçinde sizi tanımlayan hiçbir şey olmadığı için güven tamamen imzaya dayanıyor: yanıt Ed25519 anahtarımızla imzalı; imzasız, imzası tutmayan, eski bir zaman damgasından tekrar oynatılan ya da indirmeyi bizimki dışında bir konağa yönlendiren bir yanıt siteye hiç dokunulmadan atılıyor. POS kayıtlarınız, kimlik bilgileriniz ve biriken geçmişiniz WordPress seçeneklerinde ve sipariş meta'sında duruyor; güncelleme onlara hiç dokunmuyor.

Bir şey çalışmıyorsa

Banka her ödemeyi işe yaramaz bir mesajla reddediyor: Neredeyse her zaman imza. Yanlış imza hiçbir yerde hata üretmez — banka yalnızca reddeder. Mağaza numarasını, işyeri anahtarını ve o ailenin ek kimliklerini kontrol edin: hepsi imzaya girer. İşe yarayan bir ölçü şudur: bankalar imza hatasına ve geçersiz karta farklı yanıt verir; "geçersiz kart" mesajı almak imzanızın doğru olduğunun kanıtıdır.
Birden fazla POS varken dönüşte hash hatası: Geri dönüş oturumu olmayan ayrı bir istektir. MevvPos siparişin hangi POS'u kullandığını kaydeder ve o anahtarla doğrular. Bir siparişin ödendiği POS kaydını sildiyseniz doğrulama varsayılan POS'a düşer ve başarısız olabilir.
Müşteri Stripe ya da PayPal'da ödüyor ama sipariş beklemede kalıyor: Webhook adresine ulaşılamıyor ya da adres kayıtlı değil. Siparişi müşterinin dönüşü değil bildirim tamamlıyor, dolayısıyla eksik bir webhook, hiç ödeme yapmamış bir müşteriyle birebir aynı görünür. Bank API sekmesindeki adresin sağlayıcının paneline kaydedilmiş adresle aynı olduğunu ve sağlayıcının test olayının ulaştığını kontrol edin.
Square olaylarının hepsi reddediliyor: Square bildirim adresiyle gövdeyi birlikte imzalıyor. Square'de kayıtlı adres, Bank API sekmesindekiyle karakter karakter aynı olmalı — sondaki bir eğik çizgi, https yerine http, ya da bir tarafta olup diğerinde olmayan bir www yeter.
Authorize.Net olayları hiç doğrulanmıyor: Signature key, Transaction Key'den ayrı bir değer ve ikisinin yeri kolayca değişiyor. Webhook'lar yalnız Signature key ile doğrulanıyor.
Müşteri boş bir ödeme sayfasıyla karşılaşıyor ya da Öde düğmesi bir şey yapmıyor: Bir önbellek/optimizasyon eklentisi betikleri geciktiriyor. LiteSpeed'de mevvpos, jquery ve WooCommerce ön yüz betiklerini geciktirme listesinden çıkarın. Kart formu varsayılan olarak göründüğü için akış yine çalışır, ama otomatik yönlendirme çalışmaz.
Ödeme başarılı ama sipariş "beklemede" kalıyor: Banka ya da kuruluş geri dönüş adresine ulaşamamış. ?wc-api=mevvpos_callback adresinin dışarıdan erişilebilir olduğundan emin olun — bakım modu, IP kısıtı ya da sitenin önündeki bir giriş duvarı bunu engeller.
Ödeme formu aynı sayfaya geri gönderiyor: Adresi hazır gelmeyen bir banka için Gate URL alanı boş. Bankanızın ya da kuruluşun verdiği adresi yazın.
Test modu açık ama ödeme yine gerçek bankaya gidiyor: Test kipi otomatik yönlendirmeyi durdurup isteği size gösteriyor; NestPay bankalarında gate adresini değiştirmiyor. Test ederken bankanızın test adresini Gate URL alanına yazın. Stripe ve Mollie'de de anahtar adresi değiştirmiyor — orada kum havuzunu seçen şey test anahtarının kendisi.
Taksit görünmüyor: Ya o kademenin oranı sıfır değil boş, ya kart başka bankanın, ya da seçili sağlayıcı uluslararası ve hiç taksiti yok.
Güncellemeden sonra kartlar yanlış POS'a gidiyor: Eski sürümler elle yazılmış ve bir kısmı hatalı BIN aralıkları taşıyordu. Her POS'un gerçekten hangi bankada olduğuna göre kayıtlı olduğunu doğrulayın.
Yönetim ekranı stilsiz görünüyor ya da bir düzeltme gelmiyor: Tarayıcı önbelleği bayat. Sayfayı önbelleği atlayarak yenileyin.

Sınırlar

Aşağısı bilerek böyledir. Hiçbiri hata değil.

Türk banka sanal POS'unda iade yok. Hiçbir Türk ailesi iade çağrısı taşımıyor; iadeyi bankanızın kendi ekranından yapın. Uluslararası sağlayıcılar iade ediyor ve WooCommerce onlar için iade düğmesini gösteriyor.
Güncelleyici, eklentiyi nereden aldığınıza bağlı. mevvsoft.com'dan inen paket kendini bizim sunucularımızdan güncelliyor. WordPress.org'da yayımlanan paket o kodu hiç taşımıyor — orada barındırılan bir eklenti WordPress.org üzerinden güncellenmek zorunda, dolayısıyla iki paket tam olarak bu tek dosyada ayrışıyor.
Tekrarlayan ödeme yalnız uluslararası sağlayıcılarda çalışır, kayıtlı kart seçici yoktur. Saklanan tahsilat izni oluşturuluyor, yenileniyor, yeniden deneniyor ve gecikmiş olarak işaretleniyor; bir WooCommerce Subscriptions ürünü hiç kod yazmadan aboneliği kuruyor. Eksik olan: Türk banka sanal POS aileleri abonelik taşıyamıyor, müşteri ödemede kayıtlı kart seçemiyor, ve ne bir hatırlatma takvimi ne de yönetim ekranından iptal var.
Ön provizyon var, ama her yerde değil. Bir POS tutarı bloke edip daha sonra sipariş ekranından tamamını ya da bir kısmını tahsil edebilir, ya da serbest bırakabilir. Yalnız NestPay banka ailesi, Stripe, Authorize.Net ve Checkout.com taşıyor; kalan her sağlayıcıda işlem doğrudan satıştır ve ayar onlara hiç gösterilmez.
Kural tabanlı yönlendirme yok. Yönlendirme yalnız para birimine ve kartı çıkaran bankaya göre — tutara, kart markasına ya da ülkeye göre değil.
Yönlendirme her kurulumda önce para birimini, sonra kartı çıkaran bankayı soruyor. Eksik olan bundan sonrası: ikinci hesaba devretme yok, zincirleme yeniden deneme yok, tutara / kart markasına / ülkeye göre yönlendirme yok.
İki ödeme sayfası da destekleniyor. Klasik ödeme formu da WooCommerce Ödeme bloğu da sunuluyor ve taksit tablosuyla vade farkı ikisinde de aynı davranıyor. Blok, seçilen BIN'i ve taksidi Store API üzerinden yazıyor, dolayısıyla vade farkını klasik sayfadakiyle aynı kod hesaplıyor.
3D Pay Hosting bilerek reddedildi. Barındırılan sayfa PCI kapsamını kaldırıyor ama BIN'i ve taksit tablosunu da kaldırıyor — oysa Türkiye tarafının bütün değeri onların mümkün kıldığı yönlendirmede. Uluslararası sağlayıcılar tam da orada yönlendirilecek bir şey olmadığı için barındırılan sayfayla çalışıyor.
BIN düzenleyici yok. Tablo bizim tarafımızdan yönetilir ve canlı tazelemeyle birleştirilir; elle düzenlenecek bir ekran yoktur.
Yirmi altı kurum listede var ama yazılmadı. Boşluk görünsün diye listede duruyorlar.
NestPay dışındaki her sağlayıcı, gerçek bir üye işyeri hesabıyla uçtan uca doğrulanana kadar kendi beyanıyla betadır.
Sekmeler sayfa içidir. Kenar çubuğundaki satırlar MevvPos ekranını açar; sekmeler sayfanın kendi üstünden değiştirilir.

Hiçbir biçimde saklanmayanlar: kart numarası, son kullanma tarihi ve güvenlik kodu. Türkiye tarafında saklanan tek kart verisi ilk altı hane ve onların işaret ettiği banka; uluslararası sağlayıcılarda o bile yok, çünkü kart sitenizde hiç yazılmıyor. Güvenlik kodunu saklamak her koşulda yasak ve maskelenmiş olanı bile uzunluğunu sızdırır.

Tek motor: Türk banka sanal POS'ları ve uluslararası sağlayıcılar.