# Transactions

İşlemler için iki adımlı bir transaction altyapısı öngörülüyor.

1. Kullanıcı arabirimde yapmak istediği işlemle ilgili talebini iletiyor, ilgili talebin dönüşünü (masraf, komisyon, faiz, kazanım bilgileri gibi) inceleyip aynı bilgilerle emir veriyor.
* Bu süreçte işlem Consent->Order->1FA(Web:OTP, Mobile: DeviceId)->Post Security(Fraud, IVN gibi) olarak çalışıyor.
* Consent ve Order **Dynamic Linking**(her bir order bir consente bağlı olmalı.) ile ilişkilendiriliyor.
* Burada tüm servis çağrıları için güçlü kimlik doğrulaması yapılmış durumda.
2. Kullanıcı adına başka bir kurum veya kullanıcı başka bir arabirimde işlem gerçekleştirme talebinde bulunuyor. Talebi doğrulayıp sonrasında emrin gerçeleşmesini sağlıyor.
* Bu süreçte işlem Consent->2FA->Post Security->Order olarak çalışıyor.
* Consent kurumdan çağrılabilir. (Kullanıcı doğrulaması yok).
* Order kurumdan çağrılabilir (Kullanıcı doğrulaması yok).

:::info
Süreçte temel ayrıştırıcı consent servisini çağıran kullanıcının hesap sahibi olup olmaması belirliyor.
Şube ve Çağrı merkezi çalışanı dahil olmak üzere tüm müşteri dışı ödeme başlatma taleplerinde güçlü kullanıcı doğrulaması ile müşteriden onay alınarak açık bankacılık akışı çalışmalı.
:::

| Workflow | Consent Resource | Order Resource | Validation Schema |
| ---------------------------------- | ------------------------- | ------------------ | ----------------- |
| financial-transaction-manager | /eft-simulate | /eft-execute | ... |
| financial-transaction-manager | /odeme-emri-rizasi | /odeme-emri | ... |
| self-financial-transaction-manager | /doviz-alim-emri-rizasi | /doviz-alim-emri | ... |
| self-financial-transaction-manager | /doviz-satim-emri-rizasi | /doviz-satim-emri | ... |
| non-financial-transaction-manager | /vadeli-hesap-emri-rizasi | /vadeli-hesap-emri | ... |

## Workflow
* **financial-transaction-manager** Hem açık bankacılık akışlarını hem banka kullanım senaryoalrını destekleyen, fraud kontrollerini içeren temel finansal akış. Bu akışta Dynamic Linking (Web de OTP, Mobilde device id) çalışır. Tüm açık bankacılık işlemleri bu akışı kullanır.
* **self-financial-transaction-manager** Sadece müşteri hesapları içerisinde olan, fraud riski bulunmayan işlemleri yöneten akış.
* **non-financial-transaction-manager** Müşterinin maddi varlıklarını etkilmeyen işlem seti için kullanılacak akış.

*Akış (Workflow) tipleri statik ve limitli değildir. Farklı ihtiyaçlar için farklı akışlar eklenebilir.*

## Validation Schema

Consent ve Order methodlarında consolide edilen bilginin eşitliğini kontrol eder. Özünde kullanıcının onay verdiği işlem ile emir verdiği işlem arasında farklılık olmaması garanti edilir.

[
  {
    "comparer": "number",
    "compare-with": {
      "source": "consent.response",
      "data": "$.order.amount.value"
    },
    "compare-to": {
      "source": "order.body",
      "data": "$.order.amount.value"
    }
  },
  {
    "comparer": "string",
    "compare-with": {
      "source": "consent.response",
      "data": "$.order.target.iban"
    },
    "compare-to": {
      "source": "order.body",
      "data": "$.order.target.iban"
    }
  }
]

## Genel Servisler

### GET /amorphie.transactions/{transaction-consent-no}/status
Transaction durumu hakkında bilgi almak için kullanılır.

:::warning
Bilginin generik olarak verilebilmesi için **workflow** tanımları genel bir statü durum güncellemesi yapması gerekir.
:::

#### Rıza/Consent Durumları

| State | ISO 20022 | TCMB | Açıklama | Definition |
| ------------------- | --------- | ---- | -------------------- | ------------------------------------------------------------------------------------------------------ |
| Received | RCVD | B | Talep Alındı. | Transaction initiation has been received by the receiving agent. |
| WaitingProcessing | ACTC | B | Talep kabul edildi. | Authentication and syntactical and semantical validation are successful |
| PartiallyAuthorised | ACCP | B | Talep işleme alındı. | Preceding check of technical validation was successful. Customer profile check was also successful. |
| Pending | PDNG | B | Talep ilerliyor. | Transaction is pending. Further checks and status update will be performed. |
| SCACompleted | ACSP | B | Talep İşleniyor. | All preceding checks such as technical validation and customer profile were successful |
| 3FACompleted | ACSP | B | Talep İşleniyor. | All preceding checks such as technical validation and customer profile were successful |
| ReadyToOrder | ACSP | K | Talep İşleniyor. | All preceding checks such as technical validation and customer profile were successful |
| PostAuthorization | ACSP | B | Talep İşleniyor. | All preceding checks such as technical validation and customer profile were successful |
| ReadyToExecute | ACSP | Y | Talep İşleniyor. | All preceding checks such as technical validation and customer profile were successful |
| Completed | ACCC | E | İşlem Tamamlandı. | Settlement on the creditor's account has been completed. |
| Expired | CANC | S | Yetki Sonlandı. | Transaction initiation has been cancelled before execution |
| Rejected | RJCT | I | İşlem Iptal | Transaction initiation or individual transaction included in the payment initiation has been rejected. |

@startuml

@startuml

Begin : Mesaj kullanici 
Begin : arabiriminden iletildi.

state "Message-Control" as MessageControl : Hesap kontrolleri yapildi
state "3FA-Required" as 3FARequired : 3FA Doğrulama bekleniyor.

[*] --> Begin

Begin -> MessageControl : Auto 
MessageControl -> 3FARequired : Auto



Completed --> [*]

@enduml

* **B** Yetki Bekleniyor – İlk rıza talebinde
* **Y** Yetkilendirildi – Başarılı GKD sonrası yetKod üretildiğinde
* **K** Yetki Kullanıldı – Erişim Belirteci alındığında
* **E** Yetki Tamamalandı (ödeme emrine dönüştü)
* **S** Yetki Sonlandırıldı
* **I** Yetki Iptal

*Payment Initiation Service Provider / PISP açısından uyumlu küme*

İlgili statüler ile ilişki aynı zamanda alt statü kodları sağlanır.

> Eğer çağıran uygulama SignarR için hub bağlantısına sahip ve connection id sağlamış ise tüm statü değişimleri aynı zamanda connectine broadcast edilir.
> Aynı zamanda kullanıcı arabirimini yönlendirecek komutlarda bu hub üzerinden sağlanır.

#### Banka Kullanıcı Senaryosu (EFT)

1. Kullanıcı banka uygulamaları üzerinden EFT işlemi başlatır (işlemin simulate servisini çağırır)
* Transaction kaydı oluşur ve **B** olarak setlenir.
* Alt statü kodu **OB** *Onay Bekleniyor* olarak setlenir.
2. Kullanıcı ekrandan işlemi onaylar.
* Sistem içerisinde Fruad ve IVN kontrolü yapılır.
* Kontroller bitene kadar durum **B** statüsündedir.
3. Arabirim 3.Faktör onayını sağlar
* Eğer Web uygulamasında ise kullanıcı OTP veya Mobile Push approve verir.
* Eğer mobil uygulamada ise arabirim cihazın eşleşme kaydını kullanarak süreci ilerletir.
* Süreç artık Fraud/IVN gibi diğer ek kontrol süreçlerindedir. Alt statü kodu olarak sağlanır.
4. 3.Faktör, Fraud, IVN süreçler başarı ile tamalandığında akış **Order Resource** çağrısını yapar.
* Statü bu noktada **K** olarak atanır.
* Order resource başarılı yanıt verirse statü **E** olarak işaratlenir.

##### Banka Kullanıcı Senaryosu (Hesap Açma)
1. Kullanıcı banka uygulamaları üzerinden Hesap açma işlemi başlatır (işlemin simulate servisini çağırır)
* Transaction kaydı oluşur ve **B** olarak setlenir.
* Akış 3. Faktör gerketirmediğinden statü hemen **Y** statüsüne alınır.
2. Kullanıcı ekrandan işlemi onaylar.
* Ek kontrol olmadığından **K** statüsüne setlenir.
* Akış direkt **Order Resource** çağrısını yapar.
* Order resource başarılı yanıt verirse statü **E** olarak işaratlenir.

### POST /amorphie.transactions/{transaction-consent-no}/action/{action-name}

:::danger
Kurumsal ve Banka kullanıcılarının akışlarında nasıl bir yöntem kullanılmalı ? Injection noktası neresi !!!!!
:::

## Örnek Süreç

### T0 - Kullanıcı EFT Başlatır (Simulate=Request Consent=Start)

1. Kullanıcı **POST /eft-simulate** servisini çağırır/

*User Request*

{
  "source-iban" : "TR546546456546546564465",
  "target-iban" : "TR787846456546546564465",
  "target-account-name" : "Dogan Karatas",
  "amount" : 500
}

2. Gateway eft uzman sistemine çağrıyı iletir.

*EFT System Response*

{
  "source-iban": "TR546546456546546564465",
  "target-iban": "TR787846456546546564465",
  "target-account-name": "Dogan Karatas",
  "amount": 500,
  "expense": 10
}

4. (-) Eğer sonuç olumsuz ise gateway direkt olarak mesajı kullanıcıya döner.
5. (+) Eğer sonuç olumlu ise gateway transaction işlemini başlatır.
1. Zeebe üzerinde ilgili transactiona tanımlı iş akışını simulate dönmüş parametreleri ile başlatır.
2. Akıştan aldığı transaction id simulate yanıt mesajına ekler.
a. Response body içerisine **x-transation-id** olarak root property olarak ekler.
b. Response header içerisine **x-transation-id** olarak olarak ekler.

*Response to User*

{
  "source-iban": "TR546546456546546564465",
  "target-iban": "TR787846456546546564465",
  "target-account-name": "Dogan Karatas",
  "amount": 500,
  "expense": 10,
  "x-transaction-id": "40af66ff-6451-4059-b282-d590b12ed05d"
}

### T1 - Kullanıcı EFT İşlemini Onaylar (Consent=Approve=Order)

1. Kullanıcı **POST /eft-execute** servisini çağırır/

*Request*

{
  "source-iban": "TR546546456546546564465",
  "target-iban": "TR787846456546546564465",
  "target-account-name": "Dogan Karatas",
  "amount": 500,
  "expense": 10,
  "x-transaction-id": "40af66ff-6451-4059-b282-d590b12ed05d"
}

2. Zebee akışının durumuna göre response body şekillenir.
a. eğer işlem 3FA gerektiriyor ise 3FA bekleniyor mesajı dönülür.

*Response*

{
  "state": "B",
  "sub-state": "More authorization required",
  "available-actions": [
    "validate-with-otp",
    "validate-over-push",
    "validate-with-device"
  ]
}

3. Onaylamak için transaction altyapsının sağpladığı aksiyonlar kullanılır.Eğer müşteri mobil kullanmıyor ise yönetmeliğe göre web de otp ile işlem onaylar. Ek olarak resent ile tekrar otp gonderimi saglanabilir. Benzer sekilde kanal isterine gore onaylama sureci devam eder.

POST /amorphie.transactions/40af66ff-6451-4059-b282-d590b12ed05d/action/validate-with-otp
Content-Type: application/json
{
  "otp": 326564
}

POST /amorphie.transactions/40af66ff-6451-4059-b282-d590b12ed05d/action/re-send

### T2 - Kullanıcı işlemi gerçekleştirilir.

1. Akış içerisinde Fraud, IVN gibi senaryolar işletilir. Bu işlemler kapalı devre devam eder. İşlem sonucu transaction sonucu calışır.