Sanal POS Entegrasyonu Nasıl Yapılır?

Sanal POS Entegrasyonu Nasıl Yapılır? Testten Canlıya Geçiş Rehberimiz

Sanal POS entegrasyonu, e-ticaret siteniz veya uygulamanız ile ödeme altyapımız arasında güvenli bir bağlantı kurar. Müşteriniz ödeme adımına geldiğinde işlem tutarı ve sipariş referansı Paynkolay'a (bize) iletilir; kart doğrulaması ve provizyon süreci tamamlandıktan sonra sonucu sisteminize geri göndeririz.

Doğru entegrasyon yalnızca ödeme formunun görüntülenmesinden ibaret değildir. Test ve canlı ortamların ayrılması, her sipariş için benzersiz referans üretilmesi, istek ve yanıt hash’lerinin doğrulanması, 3D Secure akışlarının denenmesi ve başarısız işlemlerin doğru yönetilmesi gerekir. Bu rehber, Paynkolay Sanal POS için bu süreci işletmeniz ve teknik ekibiniz açısından adım adım açıklamaktadır.

Kısa cevap: Paynkolay olarak; Ortak Ödeme Sayfası, Linkli Ödeme ve doğrudan API gibi farklı entegrasyon yolları sunuyoruz. Teknik ekibinizin öncelikle ihtiyacınıza uygun yöntemi seçmesi, test bilgileriyle akışı kurması, başarılı ve başarısız senaryoları doğrulaması; yetkilendirmemiz tamamlandıktan sonra ise canlı uç ve canlı bilgilerle geçiş yapması gerekir.

Sanal POS Entegrasyonu Nedir?

Sanal POS entegrasyonu; sepet, sipariş, ödeme ve işlem sonucu arasındaki veri akışını ödeme altyapımıza bağlama işlemidir. Fiziksel POS cihazındaki provizyon mantığı çevrimiçi ortamda çalışır. Ancak internet üzerinden ödeme alındığı için iletişim güvenliği, kart verisinin geçtiği alanlar ve ödeme sonucunun doğrulanması ayrıca önem taşır.

Entegrasyonun kapsamı seçtiğiniz modele göre değişir. Kart alanları bizim barındırdığımız ödeme sayfasında gösteriliyorsa, işletmenizin kart verisiyle teması en aza iner. Kart bilgileri işletmenizin kendi ödeme sayfasında toplanıyorsa, güvenlik ve PCI DSS sorumluluk alanınız genişler. Bu nedenle yöntem seçimi yalnızca bir tasarım kararı değil; aynı zamanda risk, uyum ve geliştirme yükünüzü belirleyen bir adımdır.

Paynkolay Sanal POS Entegrasyon Yöntemlerimiz

1. Ortak Ödeme Sayfası (Form ile Yönlendirme)

Bu yöntemde siparişe ait gerekli alanlar HTTP POST ile bize gönderilir ve müşteri Paynkolay olarak barındırdığımız ödeme formuna yönlendirilir. Kart bilgileri doğrudan sunucularımıza iletilir. İşlem tamamlandığında sonucu, sizin tanımladığınız successUrl veya failUrl adresine göndeririz.

Ödeme sayfasını sıfırdan geliştirmek istemeyen ve kart verisinin kendi sistemleri üzerinden geçmesini azaltmak isteyen işletmeler için genellikle en ideal başlangıçtır. Dokümantasyonumuzda iframe seçeneği de anlatılmaktadır; ancak güncel iframe sayfamızda bu kullanımın önerilmediğini belirtiyoruz. Bu nedenle yeni projelerinizde varsayılan karar olarak yönlendirme akışını değerlendirmeli, iframe'i yalnızca teknik gereksinimlerinizi ve riskleri inceledikten sonra seçmelisiniz.

2. Linkli Ödeme

Linkli Ödeme’de işletmeniz bir ödeme bağlantısı oluşturur; müşteriniz bağlantıyı SMS, e-posta, WhatsApp veya başka bir dijital kanaldan açarak Paynkolay ödeme sayfamızda işlemi tamamlar. Web sitesi bulunmayan veya standart sipariş akışı dışında uzaktan tahsilat yapan işletmeler için uygundur. Sepet ve sipariş sisteminize gerçek zamanlı bağlı bir ödeme deneyimi gerekiyorsa, Ortak Ödeme Sayfası veya API daha uygun olabilir.

3. Doğrudan API Entegrasyonu

API entegrasyonu ile ödeme deneyimi üzerinde tam kontrol sağlayabilirsiniz. Açık entegrasyon sayfamızda RESTful API yapımızı, JSON veya form-data kullanımını ve test/canlı ortamlarımızı detaylandırıyoruz. Bununla birlikte, kart bilgilerinin kendi sayfanızda toplanması halinde PCI DSS kapsamı ve güvenlik sorumluluğu işletmenize ait olur. Bu model, ödeme güvenliği konusunda yetkin bir geliştirme ve operasyon ekibi bulunan projeler için değerlendirilmelidir.

4. Hazır E-ticaret Modülleri

Açık kaynak platformlar için hazır entegrasyon modülleri yayımlıyoruz. 3 Ağustos 2026 itibarıyla desteklenen platformlarımız arasında Magento 1.9 ve 2.0; OpenCart 2.0, 2.3, 3.0 ve 4.0; PrestaShop 1.6, 1.7 ve 8.1.0; ayrıca WooCommerce, GiveWP ve WHMCS yer almaktadır. Hazır modüllerimiz geliştirme sürenizi azaltabilir; yine de sürüm uyumluluğu, güncelleme durumu ve diğer ödeme eklentileriyle çakışma durumları canlıya geçmeden önce ekibiniz tarafından kontrol edilmelidir.

Hangi Entegrasyon Yöntemi Size Uygun?

Karar ipucu: En düşük geliştirme yükü her zaman en doğru seçenek değildir. Sipariş otomasyonunuz, marka deneyiminiz, güvenlik ekibinizin yetkinliği, PCI DSS kapsamınız ve bakım kapasiteniz birlikte değerlendirilmelidir.

Entegrasyona Başlamadan Önce Hazırlanması Gerekenler

- Paynkolay Sanal POS başvurunuzun ve gerekli işlem yetkilerinizin bizim tarafımızdan tamamlanmış olması gerekir.

- Alan adınız ve ödeme akışında kullandığınız sayfalar HTTPS üzerinden çalışmalı; entegrasyon sayfamıza göre TLS 1.2 veya üzeri desteklenmelidir.

- successUrl ve failUrl adresleriniz dışarıdan erişilebilir, doğru alan adınıza ait ve güvenli olmalıdır.

- Her sipariş için benzersiz bir clientRefCode üreten yapı kurmalısınız; dokümantasyonumuz bu alanda Türkçe karakter kullanılmamasını belirtir.

- Test ve canlı bilgileriniz ayrı yapılandırmalarda tutulmalı; canlı anahtarlarınız asla kod deposuna, tarayıcıya veya ekran görüntülerine eklenmemelidir.

- Sipariş durumlarınızı "ödeme bekliyor, başarılı, başarısız, iptal/iade" gibi açık bir durum modeliyle yönetmelisiniz.

- Başarılı ve başarısız ödeme, 3D Secure, mükerrer istek, zaman aşımı ve iade senaryoları için bir test planı hazırlamalısınız.

Bizimle Sanal POS Entegrasyonu: 8 Adım

1. Entegrasyon modelini seçin

Kart formunu bizim barındırmamızı istiyorsanız Ortak Ödeme Sayfası'nı; ödeme bağlantısı gönderecekseniz Linkli Ödeme'yi; tamamen özel bir akış ve tam teknik kontrol istiyorsanız API modelini değerlendirin. Desteklediğimiz bir e-ticaret platformu kullanıyorsanız önce hazır modülümüzün güncel sürümünü kontrol edin.

2. Test bilgilerinizi güvenli biçimde alın

Entegrasyon bilgileriniz Paynkolay panelinizde yetkilendirmenize göre görüntülenir. Merchant Secret Key değeriniz yalnızca sunucu tarafında ve yetkili kişilerin erişebildiği güvenli bir sır yönetimi yapısında saklanmalıdır. SX değeriniz ise seçtiğiniz Paynkolay akışında dokümanımızda tanımlandığı biçimde kullanılmalı; blog yazılarında, destek mesajlarında, ekran görüntülerinde veya gereksiz log kayıtlarında paylaşılmamalıdır. Ortak Ödeme formunda SX, standart HTML POST gövdesindeki zorunlu alanlardan biridir; bu nedenle SX ile Merchant Secret Key değerinizi aynı güvenlik kuralıyla ifşa etmemelisiniz.

3. İstek alanlarını oluşturun

Ortak Ödeme Sayfası akışımızda tutar, kart sahibinin IP bilgisi, benzersiz müşteri/sipariş referansınız, başarılı ve başarısız dönüş adresleriniz, rnd işlem zamanı değeri ve istek hash’i gibi zorunlu alanlar bulunur. Taksit, para birimi, dil, 3D Secure ve kart saklama seçeneklerini ise sözleşmeniz ve üye iş yeri yetkilerinize göre kullanabilirsiniz.

4. İstek hash’ini doğrulama kuralımıza göre üretin

Her istekte ilgili hash’in tarafınızca oluşturulmasını bekliyoruz. Güncel açık örneklerimizde Ortak Ödeme ve API isteği için SHA-512 sonucunun Base64 biçiminde iletildiği görülebilir. Alanların sırası, boş alan davranışı ve kullandığınız entegrasyon sürümü teknik dokümanımızla birebir eşleşmelidir. Hash’i tarayıcıda üretmeyin ve Merchant Secret Key’i istemci tarafına göndermeyin.

5. Test ortamımıza gönderin

Ortak Ödeme Sayfası için açık dokümantasyonumuzda test adresimizi [https://paynkolaytest.nkolayislem.com.tr/Vpos](https://paynkolaytest.nkolayislem.com.tr/Vpos), canlı adresimizi ise [https://paynkolay.nkolayislem.com.tr/Vpos](https://paynkolay.nkolayislem.com.tr/Vpos) olarak veriyoruz. Testleriniz sırasında yalnızca test yetkilerinizi ve güncel test senaryolarımızı kullanmalısınız.

6. 3D Secure ve hata senaryolarını deneyin

Sadece başarılı ödemeyi test etmek yeterli değildir. 3D doğrulamanın tamamlandığı ve yarıda kaldığı durumları, banka reddini, yetersiz limiti, yanlış hash, eksik alan, mükerrer referans, zaman aşımı ve kullanıcının sayfayı kapatması durumlarını ayrı ayrı denemelisiniz. Non-3D işlemler tarafımızdan ayrı yetki gerektirir ve SSS sayfamızda da belirttiğimiz üzere bu işlemlerin tüm riski işletmenize aittir.

7. Ödeme sonucunu sunucu tarafınızda doğrulayın

Kullanıcının successUrl adresinize gelmesi tek başına ödemenin başarılı olduğu anlamına gelmez. Ödeme sonucu dokümantasyonumuza göre, bizden dönen response hash değerini kontrol etmeli; RESPONSE_CODE değerinin 2 olduğundan ve AUTH_CODE değerinin boş, 0 veya 00 olmadığından emin olmalısınız. Dönen hash beklediğiniz değerle eşleşmiyorsa, işlemi Paynkolay’dan gelmiş kabul etmemeli ve siparişi asla "ödendi" statüsüne geçirmemelisiniz. 3D AutoComplete dönüşünde ayrıca AUTHORIZATION_AMOUNT değerini, ödeme sayfasına gönderdiğiniz amount değeriyle karşılaştırmalısınız; kurallarımıza göre bu değer gönderilen tutara eşit veya ondan büyük olmalıdır.

En kritik kontrol: Tarayıcı yönlendirmesini kesin bir sonuç kaynağı olarak değil, yalnızca doğrulanması gereken bir bildirim olarak ele alın. Siparişi sadece response hash, RESPONSE_CODE ve AUTH_CODE kontrolleriniz başarılı olduğunda; 3D AutoComplete akışında ise ek olarak AUTHORIZATION_AMOUNT kontrolü tamamlandığında güncelleyin.

8. Canlıya kontrollü geçin

Test senaryolarınızı tamamladıktan ve canlı işlem yetkileriniz tarafımızca tanımlandıktan sonra, canlı endpoint'imizi ve canlı entegrasyon bilgilerinizi ayrı bir yapılandırmadan etkinleştirin. Tam geçiş öncesinde düşük tutarlı kontrollü bir işlem yapın, sonuç doğrulamanızı, panel kaydınızı, iptal/iade süreçlerinizi ve muhasebe mutabakatınızı test edin. Canlıya geçişten sonra hata oranlarınızı ve başarısız işlemlerinizi yakından izleyin.

Ortak Ödeme Sayfasındaki Temel Alanlar

Not: Bu tablo uygulama mantığını özetlemektedir. Canlı kodunuzda alan adları, veri tipleri, sıralama ve zorunluluklar seçtiğiniz Paynkolay entegrasyon sayfasının güncel sürümünden kontrol edilmelidir.

3D Secure ve Non-3D Arasındaki Fark

3D Secure, kart sahibinin bankası tarafından ek bir doğrulama adımı uygulanmasını sağlar ve bu altyapıyı tam olarak destekliyoruz. Non-3D ödemeler ise ayrıca yetkilendirilir; SSS sayfamızda da vurguladığımız gibi, bu modelde oluşabilecek tüm riskler işletmenize aittir. Bu nedenle Non-3D akışları yalnızca iş ihtiyaçlarınızı, fraud (sahtekarlık) kontrollerinizi ve risk politikalarınızı birlikte değerlendirerek kullanmalısınız.

3D Secure kullanılması, diğer entegrasyon kontrollerinizin yerini tutmaz. Dönüş hash’ini ve işlem sonucundaki gerekli alanları yine de doğrulamalı; başarısız bir 3D akışında siparişi kesinlikle ödenmiş saymamalısınız.

Test Kontrol Listesi

- Başarılı 3D Secure ödeme: Sipariş, panel ve sonuç alanları eşleşiyor.

- 3D doğrulama reddi veya iptali: Sipariş ödenmiş görünmüyor.

- Banka reddi/yetersiz limit: Kullanıcıya teknik olmayan, güvenli bir mesaj gösteriliyor.

- Yanlış veya eksik hash: İstek reddediliyor ve sır değerleri loglanmıyor.

- Aynı clientRefCode ile tekrar deneme: Mükerrer tahsilat oluşmuyor.

- successUrl elle açıldığında veya sahte POST geldiğinde: Sipariş ödenmiş sayılmıyor.

- Tutar ve sipariş bilgisi değiştirilmiş yanıtta: Doğrulama başarısız oluyor.

- Zaman aşımı/bağlantı kesintisi: Belirsiz bir işlem otomatik olarak yeniden tahsilata dönüşmüyor.

- Taksit ve para birimi seçenekleri: Yalnızca yetkili olduğunuz konfigürasyonda gösteriliyor.

- İptal ve iade: Aynı gün iptal ve sonraki gün iade süreçleri panel/servis kurallarımıza uygun çalışıyor.

- Canlıya geçişte: Test SX/anahtar/endpoint değerlerinin kalmadığı doğrulanıyor.

- İşlem kayıtları: Kişisel veri ve kart verisi açısından uygun şekilde maskeleniyor.

Sık Görülen Entegrasyon Hataları

Test ve Canlı Bilgileri Karıştırmak

Test endpoint’imiz ile canlı SX değerinizi veya canlı endpoint’imiz ile test bilgilerinizi kullandığınızda doğrulama ve yetki hataları alırsınız. Ortam değişkenlerini ayrı tutun ve canlıya geçiş aşamasında endpoint ile kimlik bilgilerinizin aynı ortama ait olduğunu doğrulayın.

Hash Alan Sırasını veya Karakter Kodlamasını Değiştirmek

Hash hesabınızdaki alan sırası, boş değer davranışınız, URL biçiminiz ve karakter kodlamanız dokümanımızdan farklıysa, bizim ürettiğimiz değerle eşleşmeyecektir. Değeri birleştiren kodunuzu tek bir fonksiyonda tutun ve resmi örneklerimizle test edin.

Benzersiz Sipariş Referansı Kullanmamak

Aynı referansın tekrar kullanılması, mükerrer işlemlere veya eşleştirme sorunlarına yol açar. Her ödeme denemesinin siparişle ilişkisi net olmalı; tekrar denemelerde kendi tarafınızda idempotent (tekrarlanabilir) bir iş kuralı uygulamalısınız.

successUrl Dönüşünü Doğrudan Başarı Saymak

Bu, ödeme almadan siparişin "ödendi" görünmesine neden olabilecek en kritik hatadır. Dönen response hash, RESPONSE_CODE ve AUTH_CODE doğrulanmadan; 3D AutoComplete akışında ise ek olarak AUTHORIZATION_AMOUNT gönderilen tutarla karşılaştırılmadan asla sipariş statüsünü değiştirmeyin.

Gizli Anahtarları İstemci Tarafına veya Loglara Yazmak

Merchant Secret Key ve benzeri değerlerinizi JavaScript koduna, mobil uygulamanıza, hata ekranlarına, analitik araçlarına veya düz metin loglara eklememelisiniz. Gizli bir değeriniz açığa çıktıysa yalnızca silmek yeterli değildir; erişimi kesmeli ve bizimle iletişime geçerek anahtarınızı yenilemelisiniz.

Iframe’i Varsayılan Çözüm Kabul Etmek

Güncel iframe dokümantasyonumuz bu kullanımın tarafımızca önerilmediğini belirtir. Tarayıcıların SameSite, Content-Security-Policy ve X-Frame-Options gibi ayarları akışı bozabilir. Yeni kurulumlarınızda yönlendirme veya diğer resmi yöntemlerimizi önce değerlendirmelisiniz.

Güvenli Entegrasyon Kontrol Listesi

- Tüm ödeme akışınızda HTTPS ve desteklenen TLS sürümlerini kullanın.

- Merchant Secret Key ve diğer gerçek sırlarınızı sunucu tarafındaki güvenli sır yönetiminde saklayın; SX değerini seçtiğiniz akışın dokümanında tanımlandığı biçimde kullanın ve gereksiz loglardan uzak tutun.

- Gizli değerlerinizi kaynak kod, ekran görüntüsü, destek mesajı ve loglardan uzak tutun.

- Dönen hash’i sunucu tarafınızda doğrulayın; yalnızca tarayıcıdaki URL’ye güvenmeyin.

- Kart numarasını ve CVV’yi uygulama loglarına, analitik sistemlerine veya hata izleme araçlarına kesinlikle göndermeyin.

- Yönetim panelinize ve canlı anahtarlarınıza erişimi, görev için gerekli olan en az yetkiyle sınırlandırın.

- Bağımlılıklarınızı güncel tutun; ödeme akışını etkileyen güvenlik yamalarını takip edin.

- Mükerrer istekleri, anormal hata artışlarını ve beklenmeyen işlem tutarlarını izleyin.

- Anahtar sızıntısı durumları için iptal, yenileme ve olay müdahale prosedürünüzü hazır bulundurun.

PCI DSS Notu: Paynkolay’ın PCI DSS Level 1 uyumluluğuna sahip olması, işletmenizin kendi sorumluluklarını ortadan kaldırmaz. Kapsamınız; ödeme sayfasının kim tarafından sunulduğuna, kart verisinin sunucularınızdan geçip geçmediğine ve seçtiğiniz entegrasyon mimarisine göre belirlenir.

İptal ve İade Süreci Entegrasyona Dahil Edilmeli mi?

Evet. Ödeme almak kadar sipariş iptali ve iade akışının da doğru kurulması önemlidir. Açık dokümantasyonumuzda, aynı gün ve banka gün sonu tamamlanmadan yapılan geri alma işlemleri iptal; sonraki gün veya banka gün sonundan sonra yapılan işlemler ise iade olarak tanımlanmaktadır. İptal/iade servisimizde kullanılan SX değerinin, satışta kullanılan SX değerinden farklı olduğunu ve panelinizden kontrol edilmesi gerektiğini lütfen unutmayın.

İade tutarını, işlem tarihini, Paynkolay referansını ve dönüş sonucunu sipariş/muhasebe kayıtlarınızla eşleştirmelisiniz. SSS sayfamızda belirttiğimiz üzere, panelimiz üzerinden tam veya kısmi iade yapabilirsiniz. Servisimiz üzerinden kısmi iade veya sektörünüze özel bir operasyon uygulayacaksanız, canlıya geçmeden önce güncel yetkilerinizi ve iş kurallarınızı destek ekibimizle teyit etmelisiniz.

Sanal POS Entegrasyonu Ne Kadar Sürer?

Bu konuda tek bir sabit süre vermek doğru değildir. Hazır modülümüzü kullanan ve sitesi yayına hazır olan bir işletme ile; özel API, kart saklama, tekrarlı ödeme veya karmaşık sipariş akışı geliştiren bir işletmenin entegrasyon süresi aynı olmaz. Başvuru ve yetkilendirme süreçlerimiz, sitenizin hazırlığı, yazılım kapasiteniz, test senaryolarınız ve güvenlik incelemeleriniz toplam süreyi belirler.

En sağlıklı yaklaşım; yöntem seçimi, test kurulumu, hata/3D senaryoları, kullanıcı kabul testleri ve kontrollü canlı geçiş için ayrı zaman ayırmanızdır. Sözleşme durumunuzu ve güncel kampanya koşullarımızı bizimle teyit etmeden "Aynı gün kesin açılır" veya "24 saatte mutlaka tamamlanır" gibi kesin ifadelere dayalı planlama yapmaktan kaçınmanızı öneririz.

Paynkolay Sanal POS Entegrasyonunun İşletmenize Katkıları

- Tek bir entegrasyonumuz üzerinden farklı kart programlarıyla ödeme alma yapınızı kurabilirsiniz.

- Ürün ve üye iş yeri yetkilerinize göre; yurt içi kredi kartlarında taksit, yurt dışı kartlarda tek çekim gibi seçenekler sunabilirsiniz.

- Ödeme, işlem takibi, raporlama, iptal ve iade süreçlerinizi gelişmiş panelimiz üzerinden kolayca yönetebilirsiniz.

- İş modelinize göre kart saklama, düzenli ödeme ve fraud (sahtekarlık) önleme gibi ek yeteneklerimizi değerlendirebilirsiniz.

- Ortak Ödeme Sayfası, Linkli Ödeme, API ve hazır modül seçeneklerimizle farklı teknik ihtiyaçlarınıza hızlıca uyum sağlayabilirsiniz.

Bu özelliklerin kullanılabilirliği üye iş yeri sözleşmenize, sektör kurallarına, teknik yetkilendirmenize ve güncel ürün koşullarımıza bağlıdır. Komisyon, valör, taksit sayısı veya yabancı para yetkileriniz için işletmenize özel teklifimizi almayı unutmayın.

Sıkça Sorulan Sorular

Sanal POS entegrasyonumuz için yazılımcı gerekir mi?

Özel API veya form entegrasyonlarında teknik geliştirme şarttır. Kullandığınız platform için güncel hazır modülümüz bulunuyorsa kurulum yükünüz azalır; ancak yine de ayarların, testlerin ve canlı geçiş kontrollerinin teknik bir kişi tarafından yapılmasını önemle tavsiye ederiz.

Test ortamınız var mı?

Evet. Açık entegrasyon dokümantasyonumuzda test ve canlı ortamlarımızı ayrı olarak tanımlıyoruz. Test senaryolarınızı bizim sağladığımız verilerle tamamlamadan gerçek kart veya canlı anahtarlarınızı kullanmamalısınız.

successUrl sayfasının açılması ödeme alındığı anlamına gelir mi?

Hayır. Dokümantasyonumuza göre bizden dönen response hash değerini doğrulamalı, RESPONSE_CODE'un 2 olduğundan ve AUTH_CODE'un boş, 0 veya 00 dışında geçerli bir değer içerdiğinden emin olmalısınız. 3D AutoComplete dönüşünde AUTHORIZATION_AMOUNT değerini de kendi gönderdiğiniz amount değeriyle karşılaştırmalısınız. Bu kontrolleri kendi sunucunuzda tamamlamadan siparişi ödenmiş saymamalısınız.

Non-3D ödeme alabilir miyim?

SSS sayfamızda belirttiğimiz gibi, Non-3D ödemeler için tarafımızdan ayrı bir yetki tanımlanması gerekir ve bu işlemlerin tüm riskleri işletmenize aittir. Kullanılabilirlik durumunu ve risk politikalarınızı ekibimizle teyit etmelisiniz.

WooCommerce ve OpenCart için hazır entegrasyonunuz var mı?

3 Ağustos 2026 itibarıyla entegrasyon sayfamızda WooCommerce ve OpenCart 2.0, 2.3, 3.0 ve 4.0 için seçeneklerimizi listeliyoruz. Kurulumdan önce platform, PHP ve eklenti sürümü uyumluluğunuzu güncel dokümanımızdan mutlaka kontrol edin.

Kart bilgilerini kendi sunucumda saklayabilir miyim?

Kart verisinin saklanması yüksek güvenlik ve PCI DSS gereksinimleri doğurur. Kart bilgilerini kendi uygulamanızda kesinlikle düz metin olarak saklamamalısınız. Kart saklama ihtiyacınız varsa, Paynkolay olarak sunduğumuz yetkili kart saklama çözümümüzü ve teknik kurallarımızı değerlendirmelisiniz.

Entegrasyon tamamlandıktan sonra hangi metrikleri izlemeliyiz?

Başarılı işlem oranlarınızı, banka retlerini, 3D terk oranlarınızı, teknik hataları, mükerrer istekleri, ortalama yanıt sürelerini, iptal/iadeleri ve belirsiz işlem sayılarını izlemenizi öneririz. Hata kodlarını kullanıcılarınıza ham teknik metinler olarak değil, her zaman güvenli ve yönlendirici mesajlara dönüştürerek yansıtın.

Paynkolay Sanal POS’u inceleyin • Entegrasyon dokümanlarına gidin • Başvuru yapın