Başlangıç · Uçtan Uca Rehber

Sıfırdan ilk ödemeye

Bu rehber, api-yos'u kendi makinende ayağa kaldırmaktan bir bankayı bağlamaya, hesap/bakiye görmeye ve ödeme başlatmaya kadar tüm yolu adım adım gösterir. Kod bilmesen de akışı takip edebilirsin; bilirsen örnekleri doğrudan kopyalayıp deneyebilirsin.

Docker ComposeJWT ile girişRıza → GKD → Belirteç?fresh=true canlı veri
Kimler okumalı? İlk kez api-yos'a bakan bir geliştirici, sistemi test için kuran biri ya da "kullanıcı bir bankayı nasıl bağlıyor" akışını uçtan uca görmek isteyen herkes. Derinlik için Mimari, tüm uçlar için API Uçları.

1. Ortamı hazırla

api-yos üç parçadan oluşur ve hepsi Docker ile gelir: MSSQL (veritabanı), apps/api (Public API) ve apps/batch (bankalarla konuşan işçi). Önce ayarları kopyala, gizli değerleri doldur:

cp .env.example .env

# En az bunları ayarla:
#   MSSQL_SA_PASSWORD       -> SA parolası (yalnız DB + login oluşturmada; uygulamalar sa ile bağlanmaz)
#   YOS_APP_DB_PASSWORD     -> uygulama giriş parolası (api + batch yos_app olarak bağlanır)
#   CODE_AGENT_DB_PASSWORD  -> salt-okunur code_agent DB kullanıcısının parolası
#   JWT_SIGNING_KEY         -> JWT imzalama anahtarı (uzun, rastgele)
#   OHVPS_* (batch)         -> banka (HHS) bağlantı ayarları
Anahtarlar neden önemli? JWT_SIGNING_KEY giriş biletlerini imzalar; sızarsa biri başkasının yerine geçebilir. Banka erişim belirteçleri ve kişisel bilgiler de veritabanında şifreli tutulur — düz metin yok.

2. Servisleri başlat

docker compose up --build
# mssql + api-yos + batch "healthy" olana kadar bekle
ServisAdres (host)Rol
api-yoshttp://127.0.0.1:8444Public REST API — bankaya hiç bağlanmaz
batchhttp://127.0.0.1:8445Arka plan işçisi — bankayla konuşan tek taraf
MSSQL127.0.0.1:14333Paylaşılan tek veritabanı
Port karışıklığına dikkat: banka simülatörü (api-hhs) :8443, api-yos :8444, batch :8445.

3. Sağlığı doğrula

curl http://127.0.0.1:8444/api/v1/health/ready   # -> 200 OK
curl http://127.0.0.1:8445/api/v1/health/ready   # -> 200 OK
İkisi de 200 dönüyorsa sistem ayakta. ready "istek alabilirim" demek; live yalnız "süreç yaşıyor" der.

4. Kayıt ol ve token al

Sistem çok kullanıcılıdır: herkes yalnız kendi bankalarını, hesaplarını, ödemelerini görür. Parola yoktur — kullanıcıyı, api-yos'u kullanan uygulama tanıtır: uygulama kendini X-App-Key başlığındaki uygulama anahtarıyla kanıtlar, kullanıcıyı da userKey + customerNo ikilisiyle bildirir. Karşılığında JWT (imzalı dijital giriş bileti) alınır; sonraki her istekte gösterilir.

# kayıt + token (kullanıcı zaten varsa yenisi açılmaz, yine token döner)
curl -X POST http://127.0.0.1:8444/api/v1/auth/register \
  -H "Content-Type: application/json" \
  -H "X-App-Key: dev-app-key-0123456789abcdef" \
  -d '{ "userKey": "demo-user-1", "customerNo": "1001", "displayName": "Demo Kullanıcı" }'

# Yanıt:
# {
#   "accessToken":  "eyJhbGciOi...",  <- kısa ömürlü, her istekte kullan
#   "refreshToken": "d9f1c2...",      <- bitince /auth/refresh ile tazele
#   "expiresIn": 900
# }
Ayrı bir giriş ucu yok: aynı register çağrısı hem ilk kayıt hem sonraki girişlerdir — kullanıcı zaten kayıtlıysa yalnızca taze token üretilir. Geliştirme ortamında dev-app adlı uygulama, yukarıdaki anahtarla açılışta otomatik tanımlanır; anahtarlar veritabanındaki Parameters tablosunda (auth.app.*.key) yönetilir.
İki token neden var? Erişim belirteci kısa ömürlüdür (güvenlik); süresi dolunca yenileme belirteciyle /api/v1/auth/refresh çağrılır. Böylece her istekte kayıt ucuna dönmek gerekmez, sızan bir belirteç de uzun süre işe yaramaz.
Authorization: Bearer <accessToken>

5. Bir bankayı bağla

İşin kalbi. Kullanıcı "şu bankadaki hesaplarıma erişmene izin veriyorum" der; buna rıza (consent) denir. api-yos bunu doğrudan bankaya iletmez — niyet kutusuna yazar, bankayla konuşmayı batch yürütür:

Bankayı seç
GET /api/v1/hhs
Bağlanabilecek bankaların listesini al; kullanıcı birini seçer.
Rıza başlat
POST /api/v1/hhs-connections
api-yos rızayı veritabanına yazar ve aynı anda bir SyncIntent bırakır. Yanıtta kullanıcıyı bankanın onay ekranına götüren adres döner.
Batch işi devralır
SyncIntentConsumerJob
Niyeti görür, bankaya mTLS+JWS ile bağlanır, rıza kaydını başlatır.
Kullanıcı bankada onaylar (GKD)
tarayıcı yönlendirmesi
Kimlik doğrulama bankanın kendi ekranında olur; api-yos bu ekranı görmez.
Banka geri döner
GET /api/v1/hhs-connections/callback
Banka kullanıcıyı yetki koduyla bu adrese geri yönlendirir.
Belirteç alınır → Bağlandı
yetKod → erişim belirteci
Batch yetki kodunu erişim belirtecine çevirir, bağlantı "Connected" olur. Belirteç ve kişisel bilgiler şifreli saklanır.
# bankaları listele
curl http://127.0.0.1:8444/api/v1/hhs -H "Authorization: Bearer $TOKEN"

# rıza / bağlantı başlat
curl -X POST http://127.0.0.1:8444/api/v1/hhs-connections \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "hhsId": "<banka-id>" }'
# -> { "connectionId": "...", "redirectUrl": "https://banka/onay?..." }

# kullanıcı redirectUrl'de onayladıktan sonra:
curl http://127.0.0.1:8444/api/v1/hhs-connections \
  -H "Authorization: Bearer $TOKEN"
# -> status: "Connected" görene kadar bekle (birkaç saniye)
Idempotency-Key nedir? Ağ kopması olur da aynı istek iki kez gönderilirse işlem bir kez uygulanır. Para işlemlerinde zorunludur; üstüne rezerve→tamamla iki fazlı koruma biner.

6. Veriyi gör

Bağlantı Connected olduğunda batch ilk hesap/bakiye/kart verisini çekip veritabanına yazar. Public API bu sorgularda bankaya gitmez — veritabanından okur, bu yüzden hızlıdır.

# tüm bankalardaki hesaplar + bakiyeler tek listede
curl http://127.0.0.1:8444/api/v1/accounts -H "Authorization: Bearer $TOKEN"

# bir hesabın işlem geçmişi (sayfa sayfa)
curl "http://127.0.0.1:8444/api/v1/accounts/<hesapId>/transactions" \
  -H "Authorization: Bearer $TOKEN"

# kartlar
curl http://127.0.0.1:8444/api/v1/cards -H "Authorization: Bearer $TOKEN"

# anlık taze veri: bankadan canlı çeker (biraz yavaş, en güncel)
curl "http://127.0.0.1:8444/api/v1/hhs-connections/<id>?fresh=true" \
  -H "Authorization: Bearer $TOKEN"
?fresh=true nasıl çalışır? api-yos batch'e senkron bir canlı-sorgu isteği yapar; batch bankadan anlık çeker, sonucu döndürür. Ayrıntı: Canlı Okuma & PSU.

7. Ödeme başlat

Ödeme, hesap bağlamayla aynı desendedir: emir oluştur → kullanıcı bankada onaylar → banka geri döner → sonuç işlenir. Para hareketi olduğu için idempotency + iki fazlı tamamlanma devrededir.

curl -X POST http://127.0.0.1:8444/api/v1/payment-orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "sourceAccountId": "<gönderen-hesapId>",
    "amount": 125.50,
    "currency": "TRY",
    "creditorIban": "TR000000000000000000000000",
    "creditorName": "Alıcı Adı",
    "description": "Test ödemesi"
  }'

# yanıt: onay adresi -> kullanıcı onaylar -> durumu izle:
curl http://127.0.0.1:8444/api/v1/payment-orders/<id> \
  -H "Authorization: Bearer $TOKEN"

Sorun giderme

401 / 403 alıyorum

Belirteç eksik ya da süresi dolmuş. Authorization: Bearer … ekle; bittiyse /api/v1/auth/refresh ile tazele.

404 ama kaynak var sanıyorum

Muhtemelen başka kullanıcının kaynağı. Güvenlik gereği 404 döner — varlığı bile sızmaz (BOLA koruması).

Bağlantı "Connected" olmuyor

GKD onayı tamamlanmamış olabilir ya da batch niyeti henüz işlemedi. Birkaç saniye bekle; batch loglarına Loglama sayfasından (code-agent Logs sekmesi) bak.

502 · hhs_unavailable

Bankaya ulaşılamıyor. Sertifika/mTLS ayarlarını ve OHVPS_DEFAULT_HHS_BASE_URL değerini kontrol et.

Her hata RFC 7807 + makine-okunur code + traceId taşır. Tüm kodların anlamı: Hata Kodları.