Iyzipay Php Laravel Package

Product Decisions This Supports

• Market entry into Turkey (go/no-go and sequencing). iyzico is one of the dominant Turkish payment providers; this package is the official PHP client for its API. If your roadmap includes TRY pricing, Turkish-language checkout, or a Turkey launch, this package is the enabling dependency for the payments epic — it belongs in the launch-readiness checklist, not the backlog.
• Local payment method coverage as a conversion lever. The client exposes iyzico's core capabilities: 3D Secure flows, installment (taksit) payments, stored cards, pre-authorization, refund/cancel, and the hosted checkout form. Installments are a purchasing habit in Turkey, not a nice-to-have — surfacing "6 taksit" messaging on PDP/checkout is a merchandising and pricing decision this integration makes possible.
• Build vs. buy for payments. Do not build a card-processing integration. This is a MIT-licensed, vendor-maintained SDK that removes weeks of protocol work (3DS redirect handling, callback verification, installment querying). The build-vs-buy decision should be framed as "adopt the official SDK and own the orchestration layer" — not "build our own client."
• Marketplace / multi-seller business model. iyzico's marketplace product (sub-merchant onboarding, split payments, payouts) is reachable through this API surface. That is a product-shape decision — if you're evaluating a marketplace or creator-payout model in Turkey, this package is the feasibility input for that business case.
• Subscription and retention features. Saved-card and recurring/recurring-adjacent flows underpin one-click checkout, dunning, and plan-based billing for the Turkish cohort. Choosing to support saved cards is a retention decision this SDK makes cheap to test.
• Refund/chargeback operations. Back-office refund and cancellation automation can be scoped against real API capabilities rather than assumptions, shortening the CS tooling roadmap.
• Architecture decision: abstraction layer. Using this package is also a decision to introduce a PaymentGateway interface. Treat it as one adapter behind your own contract so a second provider (or a second market) doesn't force a checkout rewrite.

When to Consider This Package

Adopt it when:

• You are selling (or about to sell) into Turkey and need a locally trusted acquirer/processor rather than a cross-border-only setup.
• You need 3D Secure as a first-class flow — Turkish regulation makes strong customer authentication the default path, not an option.
• Installments are part of your value proposition or competitive parity.
• You want an official, MIT-licensed client rather than a community wrapper — vendor support matters more than star count for money movement.
• You are on PHP/Laravel (Composer-installable, fits the framework's service-container/queue/webhook patterns).
• You need marketplace split payments or sub-merchant payouts in Turkey.
• You can absorb the integration yourself: you'll still own webhook endpoints, idempotency, reconciliation, and PCI scope decisions.

Look elsewhere when:

• Turkey is not a target market — there is no reason to carry this dependency.
• You need broad multi-country coverage from a single provider; you'd be pairing this with another gateway anyway, which argues for the abstraction layer first.
• You need a strongly typed, modern PHP SDK with an active plugin ecosystem — the client is a thin, procedural-style API wrapper; expect to write your own DTOs and error mapping. The modest star count and effectively no Composer dependents mean you are the ecosystem; there is little community code, Stack Overflow corpus, or third-party tooling to lean on.
• Your stack is not PHP, or your payments work is owned by a separate service in another language.
• You require the SDK to handle your reconciliation, retries, or observability — it won't; it's a transport client.
• You are optimizing for zero vendor concentration in a market where iyzico is your only realistic local option — in that case, plan for a second acquirer from day one.

Adoption caveats to validate before committing: confirm the release cadence and changelog discipline behind the 2026-04-28 release, confirm sandbox/test-merchant access and test-card documentation, and confirm the license and support terms directly with iyzico's developer relations — star count is a poor proxy for a payment vendor's reliability.

How to Pitch It (Stakeholders)

To executives: This is the smallest possible piece of work that unlocks the Turkish market. It's an official, MIT-licensed client for iyzico — one of Turkey's leading payment providers — which means we can accept lira, offer the installment options Turkish shoppers expect, and meet local 3D Secure requirements without building payment infrastructure ourselves. Cost of adoption is engineering time, not licensing. The strategic value is market access and conversion: installments and local trust marks are the difference between a checkout that converts in Turkey and one that doesn't. The risk is concentration on a single regional provider, which we mitigate by putting it behind our own payment interface so a second provider is a config change, not a rewrite.

To engineering: Composer-installable official client, MIT, actively released. It is a transport wrapper, not a framework integration — no Laravel service provider, no typed DTOs, no retry or idempotency handling, and near-zero downstream dependents to crib from. Plan for: an adapter behind our PaymentGateway contract, our own request/response mapping and error taxonomy, explicit 3DS callback and webhook endpoints with signature verification, idempotency keys on all mutating calls, queue-based reconciliation against settlement reports, pinned version with a deliberate upgrade cadence, and contract tests against the sandbox so a silent upstream change can't break checkout. Treat the SDK as a dependency we wrap, never one we call from controllers.

To the wider business (support, finance, legal): Refunds and cancellations can be automated from day one; settlement and reconciliation will need a defined owner because the SDK reports, it doesn't reconcile. Legal should confirm data residency and card-data handling — we stay out of PCI scope by never touching PANs and routing through iyzico's hosted/3DS flows, and that constraint should be written into the integration spec before the first line of code.