Business Flow - Payments & Charges

Bu sayfa ödeme akışlarının üst seviye haritasını ve HSRC Pay'in Payment/Charge domain ayrımını açıklar.

Payment merchant'ın iş hedefidir; Charge provider seviyesindeki işlem denemesidir. Bu ayrım routing, fallback, retry, capture, refund, void, reporting ve webhook davranışını anlaşılır hale getirir.

Ödeme akışı nedir?

Ödeme akışı yalnızca endpoint çağırmak değildir; state, provider davranışı, risk, routing ve event disiplinidir.

HSRC Pay tipik olarak şu akışı izler:

1. Payment oluşturulur.
2. Payment Method seçilir veya Checkout Session içinde toplanır.
3. Confirm execution'ı başlatır.
4. Routing provider candidate'larını üretir.
5. Orchestrator seçilen aday için provider adapter pay çağrısı yapar.
6. Charge attempt oluşur.
7. Sonuç normalized result modeline çevrilir.
8. Payment state güncellenir.
9. Event/webhook merchant sistemine gönderilir.

Payment nedir?

Payment, merchant'ın müşteriden almak istediği ödeme niyeti veya iş kaydıdır. Sipariş, abonelik, fatura veya checkout işlemine karşılık gelebilir.

Payment şunları taşır:

• Amount ve currency
• Customer veya checkout session bağlamı
• Metadata
• Secure mode ve capture tercihi
• Genel lifecycle state

Payment, merchant sisteminin görmesi gereken ana ödeme kaydıdır.

Charge nedir?

Charge, provider/rail seviyesinde gerçekleşen işlem denemesi veya finansal hareket temsilidir. Authorization, capture etkisi, provider reference, attempt number, routing origin ve refund ilişkisi Charge üzerinde takip edilebilir.

Bir Payment'ın birden fazla Charge attempt'i olabilir. Özellikle routing fallback, provider timeout, soft decline veya retry senaryolarında bu model kritik görünürlük sağlar.

Neden ikisi ayrı?

Tek payment, çoklu charge attempt

Örnek senaryo:

1. Merchant 1000 TRY Payment oluşturur.
2. Confirm sırasında ilk provider soft decline döner.
3. Routing engine ikinci provider'a fallback yapar.
4. Payment aynı kalır.
5. İlk Charge declined, ikinci Charge success olur.
6. Payment SUCCEEDED (veya auto_capture: false ise AUTHORIZED) olur.
7. Merchant tek Payment görür; operasyon ekibi iki Charge attempt trace edebilir.

{
  "id": "pay_123",
  "status": "SUCCEEDED",
  "charges": [
    { "id": "ch_1", "attempt_no": 1, "status": "DECLINED" },
    { "id": "ch_2", "attempt_no": 2, "status": "CAPTURED" }
  ]
}

Hosted Checkout akışı

Hosted Checkout, kullanıcı deneyimini Checkout Session içinde yönetir.

1. Checkout Session oluşturulur.
2. Kullanıcı session URL/token ile checkout'a gelir.
3. Payment Method ve gerekli kullanıcı alanları toplanır.
4. Confirm session bağlamında tetiklenir.
5. 3DS/requires_action gerekiyorsa checkout içinde yönetilir.
6. Final state webhook veya server-side sorgu ile doğrulanır.

API-only akış

API-only modelde merchant kendi frontend ve backend sorumluluğunu taşır.

1. Merchant Payment oluşturur.
2. Kendi UI'ında Payment Method toplar veya kayıtlı method kullanır.
3. Confirm çağırır.
4. REQUIRES_ACTION gelirse paymentNextAction.url ile yönlendirme yönetir.
5. Webhook ile nihai state'i doğrular.

Capture/refund/void ilişkisi

• Capture: Ön otorizasyon sonrası tutarı kesinleştirme işlemidir.
• Refund: Başarılı capture sonrası iade sürecidir.
• Void: Capture edilmemiş authorization'ı iptal etme işlemidir.

Bu operasyonlar Payment bağlamında görünür olsa da provider/rail seviyesindeki etkileri Charge üzerinden izlenir.

Hata/decline davranışları

Successful payment tek başına yeterli test değildir. Merchant uygulaması şu sonuçları ayrı handle etmelidir:

• Hard decline: retry yapma, kullanıcıdan farklı ödeme yöntemi iste.
• Soft decline: uygun ise fallback veya retry dene.
• Timeout/unknown: idempotency ve status check ile ilerle.
• Requires action: 3DS/redirect/resume flow'u yönet.

Merchant reporting açısından anlamı

Payment merchant'ın ana raporlama kaydıdır. Charge ise operasyonel analiz kaydıdır.

Bu ayrım sayesinde merchant:

• Tek order için kaç provider attempt denendiğini görebilir.
• Fallback kullanım oranını ölçebilir.
• Provider bazlı decline ve timeout dağılımını inceleyebilir.
• Refund/capture operasyonlarını doğru finansal bağlama oturtabilir.

Webhook/event modeline etkisi

Webhook event'leri Payment state değişikliklerini merchant sistemine taşır. Charge attempt değişiklikleri ise trace ve operasyon görünürlüğü açısından önemlidir.

Best practice: Merchant order state'i Payment event'leriyle kapatın; incident ve provider analizi için Charge attempt trace'lerini kullanın.

İlgili sayfalar

• Confirm detayları için Ödeme Yaşam Döngüsü ve Confirm
• Object alanları için Data Models - Payments & Charges
• Routing fallback için Routing Simulation
• Decline davranışı için Testing Declines
• 3DS flow için 3DS Simulation

Related docs

• Data Models - Payments & Charges
• Routing Simulation
• Ödeme Yaşam Döngüsü ve Confirm
• Terminoloji ve Kısa Notlar