Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Ödeme

Paranın siparişe bağlanması

Ödeme, sipariş belgesindeki purchase bloğu ile Mongo payments kaydının birlikte işlemesidir. Sağlayıcı sonucu gelmeden kart siparişi depoda işlenmez.

Yöntemler

Sipariş ödeme yöntemi PurchasePaymentMethod enum’udur. Enum’da CASH ve CHECK durur; alıcıya sunulan ve kabul edilen yöntemler şunlardır:

DeğerAlıcı ne yapar
CARDKart / kayıtlı kart. Sağlayıcı iframe veya kayıtlı kart çekimi. Kapıda kart da bu değerdir.
TRANSFEREFT / havale. Bildirim + yetkili onayı. Kapıda havale de bu değerdir.
ACCOUNTCari bakiye. Sipariş anında düşülür.

CASH (nakit) hem çevrimiçi hem kapıda reddeder. Yetkilinin kapı tahsilat seçenekleri yalnız CARD ve TRANSFER’dir. CHECK katalogda görünebilir; ödeme seçeneği olarak bağlanmamıştır.

Çevrimiçi / çevrimdışı ayrımı ONLINE / OFFLINE alanındadır. Alıcının isOfflinePayment bayrağı kapı tahsilatına izin verir; kapı nakit değildir, kapı kart veya havaledir.

Kart

Sipariş

Kart siparişi PAYMENT_FAILED ile doğar. Alıcı ödeme ucunu çağırır.

İframe

Önce PayTR denenir. Başarısızsa Paywall. MagicPay servisi kodda vardır, bu zincirde açık değildir. Bekleyen payments kaydı PENDING yazılır.

Geri bildirim

PayTR veya Paywall webhook’u ödemeyi SUCCESS veya FAIL yapar ve payment.updated yayınlar.

Sipariş güncellenir

Başarı: sipariş PENDING olur, purchase.isPaid dolu, cari netleşir, buyer-order.created o anda yayınlanır. Başarısızlık: sipariş ödeme başarısız kalır.

Kayıtlı kart: kullanıcının paytrUtoken alanı PayTR saklı kart içindir.

Yeni mobilde servis sınırı

  1. v2, payments koleksiyonuna v1 biçimindeki bekleyen kaydı yazar ve sağlayıcı işlemini başlatır.
  2. Sağlayıcı panelindeki tek callback adresi v1'i gösterir; 3D dönüş adresleri de v1'e gider.
  3. v1 ödemeyi ve siparişi günceller, kendi ödendi zincirini çalıştırır.
  4. Yeni mobil sonucu v2 GET /orders/buyer/payments/:paymentId ucundan sorgular.

İki servis aynı sipariş ve ödeme belgelerini kullandığı için ödeme sağlayıcı callback'i v2'ye taşınmış sayılmaz. Ayrıntı: Geçiş ve veri sahipliği.

Havale

Alıcı EFT iframe veya “havale bildirdim” yolunu kullanır. Sipariş PAYMENT_WAITING kalır; banka, IBAN, dekont ve bildirim zamanı purchase.transfer içinde durur. Yetkili onaylayınca manuel başarılı ödeme kaydı oluşur ve sipariş PENDING olur.

Cari

Bakiye yeterliyse sipariş doğrudan PENDING olabilir. Hareket tipi USE_BALANCE_FOR_PURCHASE. İptalde REFUND_BALANCE_FOR_ORDER veya alıcının seçimine göre TRANSFER_TO_BALANCE_FOR_ORDER. Kart iadesi başarısızsa tutar REFUND_FALLBACK_TO_BALANCE_FOR_ORDER ile cariye yazılır.

Kapıda tahsilat

Çevrimdışı sipariş sevk edilince borç OFFLINE_PURCHASE_FOR_ORDER ile cariye işlenebilir. Teslimde tahsilat OFFLINE_PAYMENT_FOR_ORDER ile kapanır; yöntem kart veya havaledir, nakit değildir. Kurye aracındaki collectedPayments tahsilatın saha kaydıdır.

Sevk sonrası tutar farkı

Hazırlıkta miktar değişirse ödeme yeniden hesaplanır. Kart ödenmiş ve iptal kalem varsa kısmi iade denenir. Sevkta tahsil ile net fark ORDER_AMOUNT_DIFFERENCE hareketine dönebilir.

Ödeme kaydı alanları

payments koleksiyonu sadedir: kullanıcı, platform (PAYTR / PAYWALL / MAGICPAY / MANUAL), yöntem, işlem no, sipariş id, durum (PENDING / SUCCESS / FAIL), tutar, hata kodu ve mesajı. Platform, sipariş id ve tutar sonradan değişmez (şemada immutable).