• 22-10-2026, 20:33:33
    #10
    wrydex adlı üyeden alıntı: mesajı görüntüle
    Emekli yakınım var fakat ilerleyen süreçte bir sıkıntı yaşamamak için şuan bunu düşünmüyorum. Sadece bir yazılım entegrasonun kodunu almak için vergi levhası istenmesi garip. Ben ödemede almayacağım adisyon programına pos cihazını entegre edeceğim ödeme ala basınca fiziki posa yönlendircek olay bu sadece


    Fiziki POS firmalarının vergi levhası istemesi, maliye kuralları ve bankacılık denetimleri nedeniyle standart bir prosedürdür. Güvenlik ve yasal sorumluluk yüzünden bu kodlar doğrudan kişisel kullanıcılara verilmez.
    Bu durumda izleyebileceğiniz pratik yollar şunlardır:
    • Test (Sandbox) Hesapları Kullanın: API kodlarını veya dökümanları incelemek için hemen canlı sistem başvurusu yapmak zorunda değilsiniz. Birçok ödeme kuruluşu veya banka, geliştiriciler için test (sandbox) ortamı sunar. Bu ortamlarda şirket şartı aranmaz, kodları yazıp sistemi test edebilirsiniz.
    • Android POS Cihazlarını Değerlendirin: Geleneksel banka POS'ları yerine yeni nesil Android tabanlı yazarkasa POS cihazlarını (Beko, Profilo vb.) araştırın. Bunların geliştirici portallarına başvuru süreçleri bazen daha esnek olabiliyor.
    • Düşük Maliyetli Şahıs Şirketi: Şirket açmanın pahalı olduğunu düşünüyorsanız, e-Devlet üzerinden çok düşük maliyetlerle basit bir şahıs firması açabilirsiniz. Genç girişimci desteğinden yararlanabiliyorsanız vergi ve bağ-kur avantajları da elde edersiniz. Programı ileride satmayı veya ticari kullanmayı düşünüyorsanız bu adım er ya da geç gerekecektir.
    • Mevcut Çözüm Ortakları / Ara Yazılımlar: Doğrudan bankayla uğraşmak yerine, piyasadaki mevcut entegratörlerin API'lerini veya hazır çözümlerini inceleyebilirsiniz.
    Özetle; kodları incelemek ve sistemi yazmak için test hesaplarını kullanabilir, canlı sisteme geçiş aşamasında ise en düşük maliyetli şahıs şirketi seçeneğini değerlendirebilirsiniz.


    gemini amca böyle dedi umarım faydası olur olmazsa da artıkın başka arkadaşların tavsiyelerini bende takip edeceğim
  • 22-10-2026, 20:36:55
    #11
    @AlicanDumanova Sandbox ortamları var evet ama galiba her firmanın ve cihazın galiba sistemi değişiyor diye duydum. Şuanda gündemde en çok denk gelinen pos cihazı inpos olunca onlara mail atayım dedim bu yanıtı alınca üzüldüm. Artık birisinden sadece vergi numarası talep edeceğim. Sadece mail atarken kullanabilmek için
  • 22-10-2026, 20:37:17
    #12
    wrydex adlı üyeden alıntı: mesajı görüntüle
    Ödeme almak için değil ya adisyon programı yapıyorum hocam. Ya programda karttan ödeme al diyince pos cihazına yönlendircek her pos cihazınında farklı galiba en güzel gelen bana inpostu mail atınca bu yanıtı aldım
    Anladım hocam. Muhtemelen herkesin kullandığı pos cihazı için farklı entegrasyon gerekecek. Bu özelliği şimdilik akışı baştan sona test edebilmek için, fake bir pos sürecine bağlayabilirsin. Altyapıyı birden fazla driver desteklenecek şekilde geliştirirseniz, kodun %90'ı aynı kalır. Ben kendi ödeme modülümde böyle bir yol izliyorum, ödeme ekranı, başarılı başarısız ödeme sonrası hook'lar ve onay-red akışlarını fake ödeme sistemiyle test ediyorum. Paytr, iyzico ve benim uydurduğum faketr driver'ları birebir aynı hookları tetikliyor. Bence bu model size çözüm olur.
  • 22-10-2026, 20:38:43
    #13
    @limontasarim rica etsem biraz daha bilgi verebilirsin misin çok mantıklı geldi bu
  • 22-10-2026, 20:56:11
    #14
    MoR kullanın TR bankasına ödeme alabileceğiniz: dodopayments, creem.io, lemonsqueezy gibi. Claude Code ile entegrasyon da ürün oluşturma vesaire de kolaylıkla halledilebiliyor. Kolay gelsin projenizde.
  • 22-10-2026, 21:02:32
    #15
    Ben kendi php yazılımımdan örnek vereyim. Fiziki pos sistemini bilmiyorum ama mantığı kullanabilirsiniz. Neticede bir düğmeye basılacak ve size ödeme başarılı veya başarısız bilgisi dönecek, birebir aynı süreç.

    Ben sayfamda payment_form() kullanarak ödeme formunu başlatıyorum. Bu fonksiyon env veya db'den aktif driver'a bakıyor ve payment_form_paytr, payment_form_iyzico veya payment_form_faketr gibi ayrı bir fonksiyonu çağırıyor. Asıl işi yapan bu fonksiyonlar. Bunları dökümanlardaki hazır kodları kullanarak yazıyorsun.

    Bir de işin sonuç kısmı var, burası sağlayıcıdan sağlayıcıya değişebiliyor. Örn paytr sonradan callback url'ye istek atıyor, callback dosyasında kodu inline yazmak yerine ben "payment.success" ve "payment.error" hooklarını tetikliyorum. Fake formdaki success ve error düğmeleriyle de doğrudan post ile bu hookları tetikleyerek fake bir api süreci taklit ediyorum. Ödeme sonrası mail gönderimi, abonelik işlemleri, sipariş durum güncelleme işlemleri yani kodun kendisi ödeme sürecinden veya aktif driver'dan habersiz, sadece bu hookları dinliyor. Böylece fake bir ödeme formu üzerinden istediğim gibi geliştiriyorum. Paytr veya iyzico kullanmak istersem de sadece env değişikliğiyle mümkün oluyor. İleride başka bir entegrasyon gerekirse, sadece 1 adet dosya yazmam yeterli. Bu sistemi yz ile 10 dakikada kurarsınız, yıllarca rahat edersiniz

    Buradaki mantık kodu ödeme sağlayıcısından bağımsız olarak yazmanız, bu şekilde yaptığınızda gerçek entegrasyonları daha sonra da yapabilirsiniz. Şuanki geliştirme sürecinizi baltalamaz. Kod yazmanız lazımken bağkur araştırıyorsunuz mesela Müşteri gelir, hangi firmayı kullanıyor, döküman alır size iletir, 1 adet dosya yazarsınız. Olay kapanır.
  • 22-10-2026, 23:34:40
    #16
    Sadece vergi levhasıyla çözülüyorsa? Gönderelim biz... PM den yazın