- Katılım
- 21 May 2023
- Mesajlar
- 468
- Tepki
- 17
- Puan
- 18
Ödeme İçerik Planı: Yayın Kontrol Listesi
Ödeme sistemleri hakkında yanlış veya güncelliğini yitirmiş bir cümle, sıradan bir yazım hatasından daha büyük sonuç doğurabilir. Müşteri beklemediği ücretle karşılaşabilir, destek ekibi yanlış işlem adımı önerebilir veya geliştirici eski webhook davranışına göre kod yazabilir. Bu nedenle ödeme içeriği yalnız dilbilgisiyle değil, ürün davranışı ve finansal süreçle birlikte kontrol edilmelidir.
Başlıktaki 2025 ifadesi arşiv niteliğindedir; kontrol listesi Temmuz 2026'da güncellenmiştir. Bu sayfa, kapsamlı içerik stratejisinin yerine geçmez. Amacı müşteri metni, yardım sayfası, API belgesi veya operasyon prosedürü yayınlanmadan önce kanıtlanması gereken maddeleri tek bir kalite kapısında toplamaktır.
Ödeme içeriği; metin, gerçek ürün akışı, güvenlik kapsamı ve finansal kayıt birlikte doğrulandıktan sonra yayımlanmalıdır.
1. Amaç ve Kapsam Kontrolü
- İçeriğin hedef kitlesi tek cümleyle yazıldı mı: müşteri, destek, geliştirici, finans veya risk/uyum?
- Okurun içerik sonunda vereceği karar ya da yapacağı işlem tanımlı mı?
- Ödeme yolculuğunun hangi aşaması kapsanıyor: yöntem seçimi, doğrulama, sonuç, iade, itiraz veya mutabakat?
- Kapsam dışı noktalar açık mı; içerik sağlayıcı seçimi, hukuk veya uyum onayı gibi görünmediği bir işi vaat ediyor mu?
- Aynı konuyu anlatan başka sayfa varsa tutulacak ana kaynak ve bağlantı ilişkisi belirlendi mi?
“Ödeme rehberi” gibi geniş bir brief, tek metinde ücret, entegrasyon, güvenlik ve müşteri desteğini yüzeysel bırakabilir. Her içerik için çözülmesi gereken somut soruyu yazın.
2. Kaynak ve Kanıt Kontrolü
- Ücret, yöntem, ülke, para birimi ve sözleşme bilgisi sağlayıcının güncel resmî kaynağından doğrulandı mı?
- API alanı, hata kodu, webhook ve test davranışı kullanılan API sürümünün belgesine dayanıyor mu?
- PCI veya 3D Secure anlatısı PCI SSC/EMVCo gibi birincil kaynağa bağlanıyor mu?
- Mevzuat iddiası uygulanabilir ülke, müşteri ve işlem türü açısından yetkili kişi tarafından incelendi mi?
- İç ekipten gelen bilgi ekran görüntüsü, test kaydı, karar kaydı veya ürün sahibi onayıyla desteklendi mi?
- Kaynak tarihi değil, kaynağın hâlâ geçerli sürümü kontrol edildi mi?
Sağlayıcı blogu veya satış sunumu kendi ürünü için yararlı olabilir; fakat rakip karşılaştırması ve “en hızlı/en güvenli” gibi üstünlük iddiaları için bağımsız kanıt sayılmaz. Kanıt yoksa iddiayı çıkarmak, tahminle doldurmaktan daha doğrudur.
3. Tutar, Ücret ve Para Birimi Kontrolü
- Tutarın vergiler, kargo, indirim ve varsa ek ücretlerle ilişkisi açık mı?
- Ondalık ve en küçük para birimi gösterimi teknik belgeyle uyumlu mu?
- Komisyon örneği sabit, evrensel oran gibi sunuluyor mu; yoksa sözleşmeye göre değiştiği açıklanıyor mu?
- Kur dönüşümünün hangi anda ve hangi tarafça yapıldığı biliniyor mu?
- İade, kısmi iade ve yuvarlama örnekleri finans ekibinin gerçek hesabıyla eşleşiyor mu?
- Müşteri metni ile muhasebe/sağlayıcı raporundaki adlandırma birbirini yanlış yorumlatıyor mu?
Örnek hesap kullanacaksanız “temsili” olduğunu belirtin ve formülü açık yazın. Güncel olmayan gerçek para değerleri yerine değişkenlerle anlatım, içeriğin ömrünü uzatır.
4. İşlem Durumu ve Hata Mesajı Kontrolü
- “Başlatıldı”, “doğrulama gerekiyor”, “işleniyor”, “ödendi”, “başarısız”, “iptal” ve “iade” ayrılıyor mu?
- Timeout veya bağlantı kesintisi kesin başarısızlık gibi sunuluyor mu?
- Müşteriye ikinci ödeme denemesi önermeden önce işlem durumu doğrulanıyor mu?
- Hata mesajı ne olduğunu güvenli düzeyde ve sonraki eylemi açık biçimde anlatıyor mu?
- İç hata kodu, güvenlik kuralı, kart verisi veya hassas teknik ayrıntı müşteriye sızıyor mu?
- Destek makrosu, arayüz metni ve geliştirici hata tablosu aynı kanonik duruma bağlanıyor mu?
Durum kontrolü' Alıntı:
5. Checkout ve 3D Secure Metni Kontrolü
- Ödeme öncesinde yöntem, toplam tutar, para birimi ve beklenen sonraki adım görülüyor mu?
- Harici sayfa veya banka doğrulamasına geçişin nedeni kullanıcıya açıklanıyor mu?
- Frictionless ve challenge akışları “3DS her zaman SMS gönderir” gibi yanlış bir genellemeye indirgeniyor mu?
- Kullanıcının geri dönmemesi veya sayfayı kapatması hâlinde sonuç sunucuda izlenebiliyor mu?
- Başarı sayfası URL parametresine dayanarak kesin tahsilat iddiası gösteriyor mu?
- Erişilebilir alan etiketi, klavye sırası, hata ilişkisi ve odak davranışı test edildi mi?
EMVCo, 3-D Secure için frictionless ve challenge olmak üzere iki temel akışı açıklar. Sağlayıcı uygulaması farklı ayrıntılar taşıyabilir; metni gerçek test akışıyla doğrulayın.
6. API, Idempotency ve Webhook Belgesi Kontrolü
- Ödeme oluşturan/değiştiren istekte idempotency kullanım kuralı ve örneği var mı?
- Aynı anahtarın hangi işlem ve parametrelerle tekrar kullanılabileceği açık mı?
- Senkron API yanıtı ile nihai asenkron sonuç ayrılıyor mu?
- Webhook imzasının ham gövde üzerinden nasıl doğrulanacağı belgeleniyor mu?
- Yinelenen ve sırası değişen olaylara karşı olay kimliği/durum kontrolü anlatılıyor mu?
- Endpoint'in hızlı `2xx` verip ağır işi kuyrukta yürütmesi gerekiyorsa bu davranış yazıyor mu?
- Test ve canlı endpoint, anahtar, webhook sırrı ve örnekleri açıkça ayrılmış mı?
- Kullanımdan kalkacak alan veya sürüm için geçiş ve bitiş takvimi var mı?
Bir sağlayıcının örnek kodunu kopyalamak yerine kullandığınız SDK/sürümle çalıştırın. Örnek başarılı görünse bile retry, doğrulama ve hata dalları ayrıca test edilmelidir.
7. Güvenlik ve Veri Kontrolü
- Kart verisinin tarayıcı, mağaza sunucusu ve sağlayıcı arasındaki yolu doğru çizildi mi?
- “PCI uyumlu” ifadesinin hangi taraf ve hangi entegrasyon kapsamı için geçerli olduğu açık mı?
- Ödeme sayfasındaki betiklerin sahibi, gerekçesi ve değişiklik izlemesi tanımlı mı?
- API anahtarı, webhook sırrı, ham kart verisi veya kişisel veri örnek/log içinde görünüyor mu?
- Ekran görüntülerinde gerçek kullanıcı veya işlem bilgisi temizlendi mi?
- Veri saklama süresi ve erişim rolü operasyon politikasıyla uyumlu mu?
- Şüpheli işlem ayrıntısı, saldırgana risk kuralını açıklayacak biçimde yayımlanıyor mu?
PCI DSS kapsamı yalnız metin yazarı tarafından belirlenemez. Yayın, kurumun gerçek entegrasyonunu bilen güvenlik/uyum sorumlusundan doğrulama almalıdır.
8. İade, İtiraz ve Mutabakat Kontrolü
- İptal, provizyon iptali, tam iade, kısmi iade ve itiraz birbirinden ayrılıyor mu?
- Müşteriye verilen süre veya geri ödeme vaadi gerçek sağlayıcı/banka süreciyle uyumlu mu?
- İade başarısız olduğunda yeniden deneme ve inceleme yolu var mı?
- İşlem, sipariş, sağlayıcı ve banka hareketini bağlayan kimlikler belgeleniyor mu?
- Komisyon, kesinti, iade ve net ödeme farkları için sahip ve çözüm prosedürü belli mi?
- Müşteri desteği finansal kesinlik olmadan “iade tamamlandı” demeye yönlendiriliyor mu?
9. Yayın, Sürüm ve Geri Okuma Kontrolü
- İçerik sahibi ile teknik/operasyon onaylayanı kaydedildi mi?
- Bağlantılar, test kartları ve örnek istekler yayın ortamında tekrar denendi mi?
- Dil varyantları aynı ürün ve hata sözlüğünden güncellendi mi?
- Güncelleme tarihi gerçek incelemeyi mi gösteriyor, yalnız otomatik tarih mi?
- API, ücret, yöntem, mevzuat veya ürün değişikliğinde içerik sahibini uyaran tetikleyici var mı?
- Eski sürüm kaldırılıyorsa yönlendirme ve arşiv notu planlandı mı?
- Yayından sonra ürün ekranı, yardım sayfası ve destek makrosu birlikte geri okundu mu?
Son Onay Kaydı
Yayın kartında en az içerik URL'si, hedef kitle, ürün/API sürümü, birincil kaynaklar, içerik sahibi, teknik doğrulayan, uyum onayı gerekiyorsa onaylayan, son test tarihi ve bir sonraki tetikleyici bulunmalıdır. Bir madde uygulanmıyorsa boş bırakmak yerine “uygulanmaz” gerekçesini yazın.
Kontrol listesi imza toplamak için değil, çelişkiyi yayın öncesinde görünür kılmak içindir. Kritik bir nokta doğrulanamıyorsa metni kesin ifadeden arındırın veya yayını durdurun.
İç Bağlantılar
- Ödeme içerik stratejisi ve yönetişim rehberi
- Yedi adımda ödeme entegrasyonu
- Dayanıklı ödeme operasyonu
- Ödeme hataları çözüm kılavuzu
Dış Kaynaklar
- Stripe: idempotent API istekleri
- Stripe: webhook işleme ve imza doğrulama
- EMVCo: 3-D Secure akışları
- PCI Security Standards Council: PCI DSS
- PCI SSC: ödeme sayfası güvenliği ve e-skimming rehberi
Özetle
Amacı doğrulayın → iddiaları birincil kanıtla eşleştirin → tutar ve durum dilini test edin → checkout/API/webhook anlatımını gerçek akışla karşılaştırın → güvenlik ve mutabakat onayını alın → sürüm kaydıyla yayımlayın. Ödeme içeriğinin kalitesi, ne kadar ikna edici olduğundan önce ne kadar doğrulanabilir olduğuyla ölçülür.
Güncelleme: 15 Temmuz 2026
Dijital Dünyanıza Yön Veren Pusula
Ekli dosyalar
Son düzenleme:
