FinTech

VPM — Vanity Payment Manager

Hastane ödemelerini online tahsilat, iç operasyon formları ve onay süreçleriyle tek merkezde toplayan finans yönetim platformu.

VPMFinTech

Çözülmesi gereken

Farklı kanallardan gelen hasta ödemelerini doğrulamak, yetkili onayından geçirmek ve hasta/fatura verisiyle birlikte analiz edilebilir hale getirmek.

Uygulanan yaklaşım

Ödeme kaydı, çok dilli online tahsilat, kademeli onay akışı, kontrollü aktarım kuyruğu ve finans dashboard'unu ortak bir platformda birleştirmek.

Problem

Hastane operasyonlarında ödeme bilgisi tek bir yerde oluşmuyor. Bir kısmı hastayla görüşen ekipler tarafından form üzerinden giriliyor, bir kısmı hastaya gönderilen online ödeme sayfasından geliyor. Hasta, randevu ve fatura bilgileri ise ayrı bir hastane bilgi sisteminde tutuluyor.

Bu yapı elle yönetildiğinde iki şey birden zorlaşıyor: bir hastanın ödeme geçmişine hızlı erişmek ve bir dönemin cirosunu güvenle söyleyebilmek. Kayıtların kimin tarafından girildiği, kimin onayladığı ve hangi kanaldan geldiği izlenemediğinde, finansal bir rakamı savunmak da mümkün olmuyor.

Yaklaşım

VPM'i bir ödeme kayıt ekranı olarak değil, ödeme alma → doğrulama → hasta ile ilişkilendirme → analiz → satış sürecine yansıtma zincirinin tamamı olarak ele aldım. Her ödeme kaydı, hangi kanaldan geldiğinden bağımsız olarak aynı doğrulama ve onay hattından geçiyor.

Ödeme Akışı

Manuel giriş ile online tahsilat, sistemin içinde aynı noktada buluşuyor:

  1. Ödeme bilgisi iki kanaldan biriyle oluşuyor: operasyon ekibinin doldurduğu standart form veya hastaya gönderilen online tahsilat sayfası.
  2. Online ödemeler doğrudan kesin kayda yazılmıyor; önce kontrol edilebilir bir ara aşamaya alınıyor.
  3. Hasta eşleştirmesi yapılıyor; eşleşmeyen veya eksik bilgiyle gelen kayıtlar ara aşamada bekletiliyor.
  4. Yetkili kullanıcı kaydı onaylıyor veya açıklama yazarak reddediyor.
  5. Onaylanan kayıt finansal analize ve satış sürecine aktarılıyor.

Online Tahsilat Sayfası

Hastanın veya hasta adına ödeme yapan kişinin kullandığı tahsilat sayfası, kredi kartı ve banka havalesini aynı deneyimde sunuyor. Kart ödemelerinde sanal POS ve 3D Secure akışı işletiliyor; havale seçeneğinde hastaya referans kodu ve hesap bilgisi gösterilerek ödemenin takip edilebilmesi sağlanıyor.

Sayfa, ödeme yapan kişinin hastadan farklı olabileceği varsayımıyla tasarlandı — pratikte sık karşılaşılan bir durum. Referans kodu, ödeme ile hasta kaydı arasındaki bağı kuran alan olarak kullanılıyor.

Çoklu Dil ve Para Birimi

Uluslararası hasta operasyonu nedeniyle tahsilat sayfası Türkçe, İngilizce, Almanca, Fransızca, İtalyanca ve İspanyolca olarak sunuluyor. Finansal tarafta TRY, EUR, USD ve GBP birlikte ele alınıyor.

Çoklu para birimi, raporlamada ayrı bir tasarım kararı gerektirdi: farklı para birimlerindeki tutarları tek bir toplama indirgemek yerine, her para birimini kendi ekseninde izlenebilir tutmak.

Onay ve İzlenebilirlik

Girilen ödeme kayıtları doğrudan kesinleşmiyor. Finans veya yönetici yetkisine sahip kullanıcılar kaydı inceleyip onaylıyor; eksik veya hatalı bulduklarında red açıklaması yazarak geri çeviriyor. Bekleyen, onaylanan ve reddedilen kayıtlar ayrı ayrı izleniyor.

Red açıklaması bilinçli bir tercih: kaydı giren kişi neyin yanlış olduğunu görmeden düzeltemez. Her kaydın kim tarafından, ne zaman, hangi işlemle değiştirildiği de tutuluyor.

Entegrasyonlar

  • Hastane bilgi sistemi: Hasta, randevu ve fatura/ciro verileri ödeme kayıtlarıyla birlikte değerlendiriliyor. Böylece bir ödemenin hangi hasta, hangi hizmet ve hangi faturayla ilişkili olduğu görülebiliyor.
  • Satış süreci (Pipedrive): Onaylanan ödemeler ve online tahsilat sonuçları ilgili satış kaydına aktivite/not olarak yansıtılıyor. Başarısız ödemeler de işaretleniyor; satış ekibi takip edebilsin diye.
  • Ödeme sağlayıcıları: Kart tahsilatı sanal POS üzerinden, sonuç doğrulaması sağlayıcı dönüşünün kontrol edilmesiyle yapılıyor.

Dashboard ve Raporlama

Dashboard, ödeme kayıtlarının listelendiği bir ekran değil; finans ve yönetim ekiplerinin günlük takibi ile dönemsel analizini aynı yerde yapabildiği bir karar destek alanı olarak tasarlandı.

Panelde dönemsel ciro hareketi, tahsil edilen ve bekleyen tutarlar, onay bekleyen kayıt sayısı, ödeme yöntemi ve ödeme aracı bazlı dağılımlar, ürün grubu kırılımı ve iade toplamları birlikte sunuluyor. Tarih aralığı, para birimi, ödeme tipi, ödeme yöntemi ve fatura durumu üzerinden filtreleme yapılabiliyor; sonuçlar dışa aktarılabiliyor.

Kullandığım Teknolojiler

Laravel, PHP, MySQL, Redis, Blade, jQuery, Vite ve ApexCharts. Hastane bilgi sistemi, satış süreci ve ödeme sağlayıcısı entegrasyonları API ve webhook akışlarıyla yürütülüyor.

Teknik Odak

  • Manuel giriş ile online tahsilatın ortak veri modelinde birleştirilmesi.
  • Kontrol edilebilir aktarım kuyruğu ve hasta eşleştirme.
  • Kademeli, yetki seviyesine göre onay ve red akışı.
  • Çoklu para birimi ve çoklu dil desteği.
  • Referans kodu üzerinden havale takibi.
  • Fatura ve ciro verisiyle birlikte dönemsel analiz.
  • İşlem geçmişi ve denetlenebilirlik.

Karşılaştığım Problemler

Geliştirme sırasında asıl zorluk ödeme almak değil, ödemenin belirsiz kaldığı durumları tanımlamaktı:

  • Hasta kaydıyla eşleşmeyen tahsilatlar.
  • Eksik veya tutarsız bilgiyle gelen online ödemeler.
  • Aynı ödemenin farklı kanallardan iki kez kayda girmesi riski.
  • Fatura veya randevu bilgisinin ödeme sonrasında değişmesi.
  • Farklı para birimlerinin aynı raporda karşılaştırılması ihtiyacı.

Çözümler

Ara aşama ve hasta eşleştirme kuralları, belirsiz kayıtların finansal tabloya sızmasını engelliyor. Mükerrer kayıt riski, referans kodu ve kayıt durumu üzerinden kontrol ediliyor. Onay akışı, verinin analiz ekranlarına girmeden önce bir insan tarafından doğrulanmasını sağlıyor.

Raporlama tarafında ise alınan ödeme ile beklenen ödemeyi ayrı tutmak belirleyici oldu: bu ikisi tek bir sayıya karıştığında, dönem sonunda hangi tutarın gerçekten kasaya girdiği tartışmalı hale geliyor.

Tasarım Notu

Finans uygulamasında sadece toplam tutarı göstermek yeterli değil; o tutarı oluşturan kaydın nereden geldiği ve hangi süreçten geçtiği de anlaşılmalı. Bir rakamın sorgulanabilir olması, doğru olmasının ön koşulu: kaydın kaynağı ve onay geçmişi izlenemiyorsa, toplamın doğruluğunu tartışmak da mümkün olmuyor.

Önceki projeLead IntelligenceSonraki proje Vanity Appointment

Diğer projeler

Tüm projeler

BİRLİKTE ÇALIŞALIM

Bir fikrin mi var?

Yeni bir proje, iş birliği veya sadece sohbet etmek için.

İletişime Geç