Pos Laravel Package

Product Decisions This Supports

• Turkey market entry / localization roadmap. If your product roadmap includes serving Turkish merchants or buyers, virtual POS (sanal pos) support is a prerequisite before checkout can go live. This package short-circuits the "which banks, which protocol quirks" discovery work and lets you scope the integration sprint realistically.
• Build vs. buy for the acquirer layer. Direct-bank virtual POS integration is a well-defined but bank-by-bank idiosyncratic problem. This package is a credible "buy/borrow" candidate versus building per-bank adapters from scratch, which typically costs multiple engineering months per bank and carries ongoing maintenance as banks change endpoints and 3D Secure flows.
• Acquirer strategy: direct bank vs. PSP aggregator. The package supports a direct-integration posture (merchant accounts with Garanti, Akbank, İş Bankası, Yapı Kredi, etc.) instead of routing everything through iyzico/PayTR/PayU. That is a pricing and margin decision as much as an engineering one — direct virtual POS accounts often mean lower per-transaction cost and better settlement control, at the cost of more operational overhead. This package makes the direct path cheaper to evaluate.
• Checkout feature prioritization. Once you can integrate banks, the feature backlog becomes concrete: 3D Secure enrollment and fallback, installment (taksit) handling, refunds and voids, partial captures, saved cards/tokenization. This package defines the shape of that backlog and which capabilities are table stakes in the Turkish market versus differentiators.
• Failover and multi-acquirer routing. Supporting more than one bank virtual POS makes transaction routing, retry, and fallback a product-level reliability feature rather than an afterthought.
• Buy-vs-fork decision for the payments module. With an unclear license and a single-maintainer risk profile, the real decision is often "vendor this package into our monorepo and own it" versus "depend on it upstream." That decision affects the engineering roadmap and the compliance story you present to finance and legal.

When to Consider This Package

Consider adopting when:

• You are building in PHP, ideally Laravel, and your team is already comfortable with Composer-based dependencies.
• Your target market is Turkey and you intend to accept domestic cards through one or more Turkish banks' virtual POS products, either as the primary path or as a redundancy path alongside a PSP.
• You want to avoid a PSP intermediary for cost, settlement timing, or merchant-of-record reasons, and you are prepared to own merchant account onboarding with banks directly.
• You need a fast, low-cost proof of concept to validate that direct bank integration is viable before committing engineering headcount.
• Your payments surface is narrow — standard checkout, 3D Secure, installments, refunds — rather than a complex multi-currency, multi-region acquiring setup.

Look elsewhere, or plan to build/fork, when:

• Licensing is unresolved. The NOASSERTION license identifier means the repository does not declare a recognized OSI license. For a payments component this is a gating issue — legal must clear it, or you must treat the code as a reference implementation and write your own. Do not let it into a production build before that review closes.
• You need multi-country or multi-currency acquiring. This is a Turkey-specific integration library, not a global payment orchestration layer. If the roadmap includes EU, MENA, or LATAM, you will end up wrapping this inside a broader abstraction or replacing it.
• You are not on PHP. The integration logic is bank-protocol knowledge encoded in PHP; porting it is a rewrite with reference value only.
• You want a no-ops, PCI-scoped-to-the-provider posture. Direct bank virtual POS puts more of the security and compliance burden on you than a hosted PSP checkout does. If your organization is not prepared to operate that, a PSP is the right first move and this package is a later optimization.
• Maintenance risk is unacceptable. Low dependent counts and a single-maintainer profile suggest you should plan to own the code, pin versions, and monitor bank protocol changes yourself rather than assume upstream will absorb them.
• You need sophisticated orchestration out of the box — smart routing, cascading retries across acquirers, unified tokenization, dispute automation. Those are typically better served by a commercial orchestration platform.

How to Pitch It (Stakeholders)

To executives: This is a candidate to accelerate a Turkey payments launch and potentially reduce per-transaction costs by integrating Turkish bank virtual POS accounts directly instead of paying a PSP markup. It is not a drop-in global payments solution — it is a Turkey-specific, PHP-based integration library with a small maintainer base and an unresolved license designation. The recommended path is a short, time-boxed technical and legal evaluation: confirm the license, validate one bank end-to-end in a sandbox, and produce a cost comparison of direct-bank versus PSP economics. That gives us a defensible build-versus-buy recommendation within a few weeks rather than a multi-month commitment.

To engineering: Treat this as a reference implementation and integration accelerator, not an unexamined dependency. It encodes real bank-by-bank protocol knowledge — 3D Secure flows, installment handling, refunds — that is expensive to rediscover. Plan to vendor or fork it into our codebase, pin the version, and add contract tests against each bank's sandbox. Assume we own maintenance; do not assume upstream will track bank endpoint changes. Surface the license question to legal before any production code is written, and design the integration behind an internal payment interface so a PSP or a second acquirer can be swapped in without touching checkout.

To legal and compliance: The package does not declare a recognized open-source license. Before adoption we need a determination on whether the code can be used, modified, and redistributed in a commercial product, or whether we should treat it strictly as a specification and implement independently. Separately, direct bank virtual POS integration shifts a larger share of PCI DSS scope and fraud liability onto us than a hosted PSP checkout would — that trade-off should be reviewed alongside the commercial savings case.