Allmine API
Billing and Revenue

Stripe Global Payouts — go/no-go

~10 dkBackendMobil / WebTaslak

Connect payouts operasyon değerlendirmesi (ekip içi)

Mühendislik notu

Bu sayfa entegratör yol haritasından çok ekip içi operasyon/backlog içeriği taşır. Entegrasyon için API Reference ve ilgili ürün rehberlerini kullanın.

Stripe Global Payouts + Connect

Allmine Kredi -> Nakit -> Banka Çekimi

  • Belge Türü: Konsolide master rapor (detaylı)
  • Son Güncelleme: 10 Mart 2026
  • Hazırlayan: Codex araştırma ve mimari konsolidasyonu
  • Kapsam: Ürün stratejisi, teknik mimari, operasyon, risk, maliyet, go/no-go

0. Bu Doküman Nasıl Okunmalı

Bu rapor iki tür bilgi içerir:

  1. Doğrulanmış bulgu: Stripe resmi dokümanlarına dayalı net bilgi
  2. Yorum/çıkarım: Allmine iş modeline göre öneri veya tasarım kararı

Belirsizlik olan alanlar ayrıca Açık Sorular bölümünde işaretlenmiştir.

1. Yönetici Özeti (Kısa Sonuç)

  1. Allmine için “kredi -> nakit -> banka çekimi” teknik olarak mümkündür.
  2. Riskin ana kaynağı teknik değil; uyumluluk, fon akışı sorumluluğu ve operasyonel mutabakattır.
  3. Global Payouts hızlı MVP için uygun olabilir; uzun vadeli creator economy için Connect daha güçlü temeldir.
  4. Çekilebilir kredi politikasını (earned vs non-earned) net ayırmadan canlıya çıkış NO-GO olmalıdır.
  5. Minimum güvenli MVP eşiği: withdrawable ledger + hold + state machine + webhook idempotency + daily reconciliation.

2. Kaynak Metodolojisi

Araştırmada yalnızca Stripe’ın birincil kaynakları kullanıldı:

  1. docs.stripe.com ürün ve API dokümantasyonu
  2. stripe.com/legal sözleşme/koşul sayfaları
  3. Stripe changelog sayfaları

Bu rapordaki referanslar bölümünde tüm kaynaklar listelenmiştir.

3. Doğrulanmış Stripe Bulguları

3.1 Global Payouts ürün sınırları ve kapsam

  1. Global Payouts sayfası “Public Preview” statüsünü gösteriyor. [R1]
  2. Recipient tarafında Stripe hesabı açmadan payout alma akışı var. [R1]
  3. “Send money” sayfası 85 ülkeye gönderim ifadesini içeriyor. [R3]
  4. 28 Ocak 2026 changelog’unda ek ülke genişlemesi duyurulmuş. [R16]

3.2 Çekirdek teknik akış (Global Payouts)

  1. FinancialAccount fon kaynağı olarak kullanılıyor. [R1]
  2. Recipient için Account (v2) kullanılıyor. [R1]
  3. Ödeme yöntemi PayoutMethod; çıkış işlemi OutboundPayment. [R1]
  4. Payout method kurulumunda OutboundSetupIntents öneriliyor. [R3]

3.3 Recipient onboarding seçenekleri

  1. Dashboard/Stripe hosted recipient creation:
    • Recipient link e-posta ile gönderildiğinde 3 gün geçerlilik bilgisi var. [R5]
    • Recipient doğrulama koduyla bilgiyi tamamlıyor. [R5]
  2. Account Links (Stripe-hosted form):
    • Link tek kullanımlık ve kısa ömürlü (10 dk) davranışına sahip. [R6]
    • Form dönüşünde v2.core.account_link.returned event’i işlenmeli. [R6]
  3. API-first recipient creation:
    • Doküman, karmaşıklık ve uyumluluk yükü nedeniyle çoğu ekip için önerilmediğini belirtiyor. [R7]

3.4 Gönderim yöntemleri, hız ve limitler (send money)

  1. Standart/wire/instant seçenekleri var (ülkeye göre). [R3]
  2. US sender için örnek hız:
    • Standard: 2-3 iş günü
    • Wire: 1 iş günü
    • Instant debit card: anlık
  3. Cross-border standard hız aralığı dokümanda 1-7 iş günü olarak geçiyor. [R3]
  4. Limit örnekleri:
    • US standard: min 1 USD, max 1,000,000 USD
    • US wire: min 100 USD, max 10,000,000 USD
    • US instant card: max 9,999 USD
    • UK standard: max 1,000,000 GBP [R3]
  5. Bazı yöntemler için reversal destek kısıtlı; wire/debit için geri alma varsayımı riskli. [R3][R4]

3.5 Payout yaşam döngüsü ve operasyon

  1. processing, posted, failed, returned, canceled durumları mevcut. [R4]
  2. Doküman posted durumunu başarıyla alıcıya ulaşan ödeme olarak tanımlar. [R4]
  3. returned ve failed senaryoları için uygulama içi rollback zorunlu. (yorum/çıkarım)
  4. Reversal tablosunda bazı koridorlarda destek yok. [R4]

3.6 Webhook ve event altyapısı

  1. Global Payouts başlangıç akışında Event Destinations + Workbench öneriliyor. [R2]
  2. Event Destinations tarafında hesap başına destination sınırı ve event retention kısıtları var. [R13]
  3. Stripe API v2 ile “thin events” yaklaşımı önemli; event sonrası resource fetch desenini gerektiriyor. [R13][R14]
  4. Global Payouts tarafında payout method event’leri için 2026 changelog kayıtları mevcut. [R17][R18]

3.7 Fund balance ve raporlama davranışları

  1. Global Payouts fonlama tarafı financial account merkezli çalışıyor. [R1][R2]
  2. Manage Payouts/Reports tarafında fee/rapor görünürlüğü gecikmeli yansıyabilir; operasyon SLA’sı buna göre tasarlanmalı. [R4]

3.8 Fiyatlandırma (doğrulanmış çerçeve)

  1. Payout maliyeti tek kalem değil:
    • Base payout fee
    • Cross-border yüzde
    • FX yüzde [R9]
  2. Priçing tablosu gönderici ülke, alıcı ülke ve döviz koridoruna göre değişiyor. [R9]
  3. Türkiye için cross-border oran tablosunda 0.75% satırı bulunuyor. [R9]

4. Connect Tarafı (Karşılaştırmalı Derinlik)

4.1 Connect’in güçlü olduğu alanlar

  1. Connected account lifecycle yönetimi (onboarding + payouts) daha doğal akıyor. [R11][R12]
  2. Karmaşık marketplace finans kurgusunda daha güçlü model sunuyor. (yorum/çıkarım)
  3. Cross-border payout priçing modeli farklı bir çerçevede (%0.25 gibi koridor bazlı ücretler) ele alınıyor. [R11]

4.2 Connect sınırlamaları

  1. Belirli kullanım türlerinde tam Service Agreement zorunluluğu gibi sözleşmesel sınırlar var. [R11]
  2. Bazı payout event akışlarında v1 event tipleriyle uyumluluk gerekliliği belirtiliyor. [R12]

4.3 Global Payouts vs Connect doküman mesajı

  1. Stripe compare sayfası; uyumluluk, fon yönetimi ve kullanım tipine göre ayrımı açık söylüyor. [R10]
  2. Global Payouts overview’de de “segregated funds / licensing” ihtiyaçlarında Connect’e bakılması gerektiği notu var. [R1]

5. Hukuki ve Uyumluluk Perspektifi (Allmine için kritik)

5.1 Doğrulanan sözleşme sinyalleri

  1. Global Payouts legal metinlerinde recipient ile doğrudan ilişki oluşmaması ve işlem limitleri gibi hükümler bulunuyor. [R22]
  2. Bölgesel sözleşme farklılıkları olabileceği için canlıya çıkışta ülke bazlı hukuk teyidi zorunlu. (yorum/çıkarım)

5.2 Allmine için çıkarım

  1. “Kredi”nin ekonomik anlamı büyüdükçe regülasyon riski artar.
  2. Özellikle çekilebilir kredi kaynak ayrımı yoksa lisans/uyumluluk riski büyür.
  3. Bu nedenle teknik geliştirme başlamadan önce hukuk + Stripe temsilcisi ile model onayı alınmalı.

6. Allmine Mevcut Kod Tabanı Etki Analizi

Mevcut güçlü noktalar:

  1. Stripe webhook signature doğrulama katmanı var.
  2. Stripe event idempotency şeması var.
  3. Kredi transfer use-case’lerinde DB transaction deseni var.
  4. Kullanıcı transaction history agregasyon yapısı var.

Eksik kalan alanlar:

  1. Tek creditBalance alanı; withdrawable ayrımı yok.
  2. Payout request/attempt domain modeli yok.
  3. Outbound payout webhook handler yok.
  4. Reconciliation ve finance ops dashboard yok.
  5. Transaction history’de cash-out tipleri yok.

İlgili kod referansları:

  1. src/integrations/stripe/stripe-webhook.controller.ts
  2. src/integrations/stripe/services/stripe-webhook.service.ts
  3. src/integrations/schemas/webhook-idempotency.schema.ts
  4. src/users/use-cases/send-credits.use-case.ts
  5. src/users/dto/user-transaction-history-item.dto.ts
  6. src/balance/dto/balance-change-event.dto.ts
  7. src/credit-packages/schemas/credit-transaction.schema.ts

7. Önerilen Hedef Mimari (Detay)

7.1 Ledger ayrımı

Kullanıcı finans durumunu en az şu alanlarda ayırın:

  1. spendableCredits
  2. withdrawableCredits
  3. withdrawalHoldCredits

7.2 Yeni koleksiyonlar

  1. payout_recipients
  2. payout_methods
  3. payout_requests
  4. payout_attempts
  5. payout_ledger_entries

7.3 Payout request state machine

  1. REQUESTED
  2. ON_HOLD
  3. SUBMITTED_TO_STRIPE
  4. PROCESSING
  5. POSTED
  6. FAILED
  7. RETURNED
  8. CANCELED

7.4 İşlem akışı (öneri)

flowchart LR
  A["User withdraw request"] --> B["Eligibility + risk + limits"]
  B --> C["Move withdrawable -> hold (DB tx)"]
  C --> D["Create/verify recipient + payout method"]
  D --> E["Create outbound payment (Idempotency-Key)"]
  E --> F["Webhook status updates"]
  F --> G["POSTED => finalize"]
  F --> H["FAILED/RETURNED/CANCELED => release hold + rollback"]

7.5 API kontrat taslağı

  1. POST /api/v1/payouts/recipients/onboarding-link
  2. GET /api/v1/payouts/eligibility
  3. POST /api/v1/payouts/requests
  4. GET /api/v1/payouts/requests/me
  5. GET /api/v1/payouts/requests/:id
  6. POST /api/v1/stripe/global-payouts/webhook

7.6 Idempotency ve concurrency prensipleri

  1. Stripe create çağrılarında Idempotency-Key zorunlu. [R3]
  2. payout_request_id + attempt_no unique index.
  3. Webhook event-id tablosu + stale-processing kuralı.
  4. posted dışında hiçbir durum “final success” işaretlenmemeli.

8. Ücret ve Birim Ekonomi (Detay)

8.1 Formül

Toplam Stripe Maliyeti = Sabit Ücret + (Brüt Tutar x Cross-border %) + (Brüt Tutar x FX %)

8.2 Örnek senaryo (US sender, TR recipient varsayımı)

Varsayım seti (priçing tablosu örnek satırları):

  1. Sabit: 1.50 USD
  2. Cross-border: 0.75%
  3. FX: 1.00%
Brüt TutarSabitCross-borderFXToplam MaliyetEfektif Oran
100 USD1.500.751.003.25%3.25
500 USD1.503.755.0010.25%2.05
1000 USD1.507.5010.0019.00%1.90

8.3 Ürün etkisi

  1. Düşük tutarda sabit fee nedeniyle marj baskısı çok yüksek.
  2. Minimum çekim eşiği gerekir.
  3. “Tahmini net geçecek tutar” UI’da talep öncesi gösterilmeli.

9. Risk Kataloğu (Detaylandırılmış)

9.1 Regülasyon riski

Risk:

  1. Çekilebilir kredi yapısı stored-value/e-money sınırına yaklaşabilir.

Kontrol:

  1. Earned vs non-earned ayrımı.
  2. Hukuki sınıflandırma dokümanı.
  3. Country-by-country canlı uygunluk teyidi.

9.2 Fraud riski

Risk:

  1. Satın al -> hızlı çekim döngüsü
  2. Collusion/fake earning
  3. Çoklu hesap abuse

Kontrol:

  1. Velocity limitleri (günlük/haftalık)
  2. Hesap yaşına göre limit
  3. Risk score eşiklerinde manuel review

9.3 Operasyon riski

Risk:

  1. Returned payout sonrası kullanıcı şikayetleri
  2. Geciken webhook
  3. Backfill eksikliği

Kontrol:

  1. Retry/backfill worker
  2. Ops dashboard (timeline + stripe ref)
  3. Incident runbook + SLA

9.4 Likidite riski

Risk:

  1. Stripe financial account prefund yetersizliği

Kontrol:

  1. Prefund alarm eşiği
  2. Dinamik payout limitleri

10. Test Stratejisi (MVP için zorunlu)

10.1 Teknik testler

  1. Webhook signature doğrulama
  2. Event replay/idempotency
  3. Concurrency (aynı request’in çift submit’i)
  4. Rollback doğrulaması (failed/returned/canceled)

10.2 Stripe sandbox testleri

  1. Recipient onboarding happy-path
  2. Payout success senaryosu
  3. Payout failure test kodu senaryoları [R8]
  4. Payout returned simülasyonu [R8]

10.3 Finans testleri

  1. Ledger mutabakatı
  2. Stripe raporu vs internal ledger karşılaştırması
  3. Fee ve net tutar doğrulaması

11. Uygulama Planı (6-8 Hafta)

  1. Faz 0 (1-2 hafta): Hukuk + Stripe eligibility + ürün politika onayı
  2. Faz 1 (1-2 hafta): Ledger ayrımı + domain model + migration
  3. Faz 2 (1-2 hafta): Recipient onboarding + payout orchestration + webhook
  4. Faz 3 (1 hafta): Reconciliation + ops dashboard + alerting
  5. Faz 4 (1 hafta): Kısıtlı pilot + kademeli rollout

Çıkış kriterleri:

  1. Rollback ve idempotency testleri yeşil
  2. Mutabakat raporu tutarlı
  3. Ops runbook aktif

12. Allmine İçin Go/No-Go Karar Ağacı

flowchart TD
    A["Başlangıç: Creator kredilerini banka hesabına çekme hedefi"] --> B{"Çekilebilir kredi kaynağı net ayrıldı mı? <br/>(earned vs promo/purchase)"}
    B -->|Hayır| N1["NO-GO: Önce ledger/politika ayrımı"]
    B -->|Evet| C{"Kullanıcı bazlı finansal lifecycle karmaşık mı? <br/>(negatif bakiye, vergi, geri düşüm)"}
    C -->|Evet| G1["GO: Connect öncelikli yol"]
    C -->|Hayır| D{"Stripe eligibility + ülke kapsamı onaylı mı?"}
    D -->|Hayır| N2["NO-GO: Uygunluk teyidi beklenmeli"]
    D -->|Evet| E{"MVP güvenlik eşiği tamam mı? <br/>hold + state machine + idempotency + reconciliation"}
    E -->|Hayır| N3["NO-GO: Operasyonel risk yüksek"]
    E -->|Evet| G2["GO: Global Payouts ile kontrollü pilot"]

12.1 Global Payouts GO koşulları

  1. Çekilebilir kredi ayrımı hazır
  2. Recipient onboarding tamam
  3. Hold + rollback çalışıyor
  4. Webhook idempotency aktif
  5. Günlük mutabakat raporu aktif
  6. Hukuk ve Stripe eligibility onayı var

12.2 Connect GO koşulları

  1. Marketplace/creator economy büyümesi hedefleniyor
  2. Finansal lifecycle karmaşıklığı artıyor
  3. Vergi/uyumluluk yükünü Stripe’a daha fazla taşımak isteniyor

13. Açık Sorular (Stripe ile netleştirilecek)

  1. Allmine tüzel yapısı ve hedef ülkeler için Global Payouts canlı eligibility durumu nedir?
  2. Hedef ülke/para birimi için izinli payout method seti ve reversal davranışı nedir?
  3. Hedef koridorlarda beklenen settlement gecikmesi nedir?
  4. Priçing tablosunda hedef hacim için özel ticari koşul var mı?
  5. Event type seçimi ve API v2 sürüm pinleme stratejisi nasıl uygulanmalı?

14. Nihai Öneri

  1. Kısa vadede: Global Payouts ile sınırlı pilot yapılabilir.
  2. Pilot öncesi: ledger ayrımı + rollback + mutabakat tamamlanmadan canlıya çıkılmamalı.
  3. Orta-uzun vadede: creator ekonomisi büyüme stratejisi varsa Connect hedef mimari olarak tutulmalı.

15. Referanslar (Resmi Kaynaklar)

Tüm referanslar 10 Mart 2026 tarihinde doğrulandı.

  1. [R1] Global Payouts Overview: https://docs.stripe.com/global-payouts
  2. [R2] Get Started (Global Payouts): https://docs.stripe.com/global-payouts/get-started
  3. [R3] Send Money: https://docs.stripe.com/global-payouts/send-money
  4. [R4] Manage Payouts: https://docs.stripe.com/global-payouts/manage-payouts
  5. [R5] Recipient Creation Options: https://docs.stripe.com/global-payouts/recipient-creation-options
  6. [R6] Stripe-hosted Recipient Creation: https://docs.stripe.com/global-payouts/stripe-hosted-recipient-creation
  7. [R7] API Recipient Creation: https://docs.stripe.com/global-payouts/api-recipient-creation
  8. [R8] Testing Global Payouts: https://docs.stripe.com/global-payouts/testing
  9. [R9] Priçing: https://docs.stripe.com/global-payouts/priçing
  10. [R10] Compare with Connect: https://docs.stripe.com/global-payouts/compare-with-connect
  11. [R11] Connect Cross-border Payouts: https://docs.stripe.com/connect/cross-border-payouts
  12. [R12] Connect Payouts: https://docs.stripe.com/connect/payouts-connected-accounts
  13. [R13] Event Destinations: https://docs.stripe.com/event-destinations
  14. [R14] Webhooks (Stripe API): https://docs.stripe.com/webhooks
  15. [R15] Account Link Object (v2 core): https://docs.stripe.com/api/v2/core/account-links/object
  16. [R16] Changelog (2026-01-28 new countries): https://docs.stripe.com/changelog/clover/2026-01-28/cross-border-payouts-new-countries
  17. [R17] Changelog payout_method.created event: https://docs.stripe.com/changelog/clover/2026-01-28/payout-method-created-event
  18. [R18] Changelog payout_method.updated event: https://docs.stripe.com/changelog/clover/2026-01-28/payout-method-updated-event
  19. [R19] Changelog Accounts v2 events: https://docs.stripe.com/changelog/clover/2026-01-28/accounts-v2-events
  20. [R20] Changelog Enhance Money Management APIs: https://docs.stripe.com/changelog/clover/2026-01-28/enhance-money-management-apis
  21. [R21] Global Payouts Services Terms (legal): https://stripe.com/legal/global-payouts
  22. [R22] Global Payouts Services Terms (regional variant): https://stripe.com/at/legal/global-payouts

16. Not

Bu rapor hukuki danışmanlık değildir. Lisans, vergi ve ülke bazlı düzenleyici yükümlülükler için hukuk danışmanı ve Stripe temsilcisiyle birlikte doğrulama zorunludur.

17. Uygulama Backlog Dokümanı

Bu raporun mühendislik kırılımı ve sprintlenebilir görev listesi için:

docs/stripe-payouts-implementation-backlog.md

RevenueCat credit packages yapılandırma

Dashboard ve ürün kimliği yapılandırması

Stripe payouts implementation backlog

Payout implementasyon backlog (ekip içi)

On this page

Stripe Global Payouts + ConnectAllmine Kredi -> Nakit -> Banka Çekimi0. Bu Doküman Nasıl Okunmalı1. Yönetici Özeti (Kısa Sonuç)2. Kaynak Metodolojisi3. Doğrulanmış Stripe Bulguları3.1 Global Payouts ürün sınırları ve kapsam3.2 Çekirdek teknik akış (Global Payouts)3.3 Recipient onboarding seçenekleri3.4 Gönderim yöntemleri, hız ve limitler (send money)3.5 Payout yaşam döngüsü ve operasyon3.6 Webhook ve event altyapısı3.7 Fund balance ve raporlama davranışları3.8 Fiyatlandırma (doğrulanmış çerçeve)4. Connect Tarafı (Karşılaştırmalı Derinlik)4.1 Connect’in güçlü olduğu alanlar4.2 Connect sınırlamaları4.3 Global Payouts vs Connect doküman mesajı5. Hukuki ve Uyumluluk Perspektifi (Allmine için kritik)5.1 Doğrulanan sözleşme sinyalleri5.2 Allmine için çıkarım6. Allmine Mevcut Kod Tabanı Etki Analizi7. Önerilen Hedef Mimari (Detay)7.1 Ledger ayrımı7.2 Yeni koleksiyonlar7.3 Payout request state machine7.4 İşlem akışı (öneri)7.5 API kontrat taslağı7.6 Idempotency ve concurrency prensipleri8. Ücret ve Birim Ekonomi (Detay)8.1 Formül8.2 Örnek senaryo (US sender, TR recipient varsayımı)8.3 Ürün etkisi9. Risk Kataloğu (Detaylandırılmış)9.1 Regülasyon riski9.2 Fraud riski9.3 Operasyon riski9.4 Likidite riski10. Test Stratejisi (MVP için zorunlu)10.1 Teknik testler10.2 Stripe sandbox testleri10.3 Finans testleri11. Uygulama Planı (6-8 Hafta)12. Allmine İçin Go/No-Go Karar Ağacı12.1 Global Payouts GO koşulları12.2 Connect GO koşulları13. Açık Sorular (Stripe ile netleştirilecek)14. Nihai Öneri15. Referanslar (Resmi Kaynaklar)16. Not17. Uygulama Backlog Dokümanı