Why Iyzico comes first in Turkey
Global payment providers do not fit every local use case. In Turkey, company structure, merchant onboarding, mandatory 3DS, and cardholder behavior differ from a typical Stripe-first workflow. Teams used to Stripe may find Iyzico panels and flows less polished at first glance — but for TL billing, local compliance, and merchant account reality, it remains the default choice for many domestic products. The same provider can power event checkout, SaaS subscriptions, or marketplace payments; what changes is integration depth and operational discipline, not the logo on the checkout page.
Connecting the SDK is the easy part
Real complexity appears after checkout opens: what the user sees on decline, whether their order still exists after 3DS redirect, whether the UI claims success before the webhook arrives, and whether refunds update inventory, tickets, or subscription state automatically. Shipping without answers to these questions is why sandbox-green flows break on the first production Friday.
Where integrations usually break
Non-idempotent webhooks process the same payment twice — common under high-volume ticket sales because providers legitimately retry callbacks. Lost session-to-order mapping after 3DS return strands users in “I paid but have no order,” especially in mobile browsers and in-app webviews. Sandbox behavior diverges from production merchant settings: installments, BIN rules, callback URLs. Cookie and redirect issues between webviews and hosted payment pages silently drop sessions. Showing “payment complete” before webhook confirmation increases support load and dispute risk.
How to model payment state on the backend
Keep payment status in a single payment_intent or order_payment table: pending, requires_action, paid, failed, refunded. The UI reads this state; webhooks only update it — they should not re-run business logic. Webhook handlers in NestJS, Go, or similar stacks need signature verification and idempotency keys; duplicate event or payment IDs must no-op. Orders, tickets, or subscriptions reference payment state; fulfillment must not run until paid is confirmed. In high-traffic ticketing, this separation prevents double issuance and inventory drift.
Production testing and mobile vs. web
Sandbox success does not guarantee production merchant panel behavior. Before launch, run a low-amount live card test: 3DS return, webhook delay, and refund paths only prove out this way. On mobile, in-app digital goods fall under store rules; physical services, event tickets, or real-world fulfillment are different — clarify this before choosing payment architecture. Web checkout plus deep link return works on mobile but carries UX cost. Native IAP, external web payment, or hybrid models depend on product and distribution channel; there is no universal answer.