Ana içeriğe atla
Ödeme orkestrasyonu abonelik limitleriyle korunur. Limitler yalnız raporlama amaçlı değildir; POS oluşturma ve ödeme tamamlama sırasında atomik olarak uygulanır.

​
Kullanım metrikleri

GET /payments/usage, firma için iki temel metriği gösterir:
  • virtual_pos_count: Yapılandırılmış sanal POS bağlantısı sayısı
  • successful_payment_count: Aktif abonelik dönemindeki başarılı ödeme sayısı
POS oluşturulurken kapasite rezerve edilir. Oluşturma başarısız olursa rezervasyon geri alınır. Ödeme kotası session claim sırasında ayrılır; başarısız veya tamamlanmamış işlemde geri bırakılır, başarılı işlemde deterministik usage event ile yalnız bir kez tüketilir.

​
İzlenecek operasyon göstergeleri

  • Intent başarı, ret, teknik hata ve unknown oranı
  • Sağlayıcı ve POS bazında başarı oranı
  • 3DS’e yönlenen ve tamamlanan işlem oranı
  • Failover sayısı ve hangi hata grubundan tetiklendiği
  • Payment intent’in processing veya unknown durumda kalma süresi
  • Webhook teslim süresi, retry sayısı ve dead olaylar
  • İptal/iade başarısı ve işlem süresi
  • POS credential doğrulama ve adaptör sağlık durumu
  • Kalan POS ve başarılı ödeme kotası

​
Alarm önerileri

​
Operasyonel değişiklikler

Oran planını yayınlamadan, credential döndürmeden veya POS’u production’da aktive etmeden önce iki kişi kontrolü uygulamanız önerilir. Değişiklik saatini, uygulayan kullanıcıyı, POS kimliğini ve plan sürümünü kendi operasyon kaydınızda tutun.
Kalan kota sıfıra yaklaşırken yeni ödeme kabul etmeye devam edeceğinizi varsaymayın. Ödeme sayfasını açmadan önce kullanım ve abonelik durumunu izleyin; müşteri deneyimi için kontrollü hata mesajı hazırlayın.

İlgili konular

Abonelik ve kullanım limitleriÖdeme durumları ve idempotencySandbox ve test senaryolarıBelirsiz işlemler ve durum mutabakatıMimari ve güven sınırı