Mpay24 Php Laravel Package

Product Decisions This Supports

• Payment provider selection (build vs. buy): Informs whether mPAY24 is a viable PSP for an Austrian/DACH-focused checkout. The SDK's existence and maturity are an input to that decision — but not the deciding one; commercial rates, payment-method coverage (cards, EPS, SEPA, wallets), and settlement terms should drive it.
• Integration approach: Use the official SDK versus calling the mPAY24 REST endpoints directly. The package is a thin vendor wrapper — it saves boilerplate for payment initiation, tokenization, transaction status, and refunds, but adds a dependency you must track.
• Gateway abstraction strategy: Because this is provider-specific, adopting it is a commitment to a concrete gateway. This is the moment to decide whether payments sit behind an internal PaymentGateway interface (recommended) or leak mPAY24 types into domain code.
• Roadmap scoping: Checkout, saved cards/tokenization, SCA/3-D Secure flows, refunds, and partial captures — confirm which of these the SDK actually covers before committing roadmap dates; gaps mean custom HTTP work regardless.
• Maintenance budgeting: A last release in August 2022 and ~13 stars implies minimal community surface. If adopted, budget for owning compatibility (PHP 8.2/8.3, Laravel 10/11) and for a fork-or-replace contingency.
• Market expansion: For a DACH launch, mPAY24 is a legitimate local-rail option; for a US/global-first product it is almost certainly irrelevant scope.

When to Consider This Package

Consider it when:

• You have already selected mPAY24 as your PSP (merchant account, contract, or parent-company mandate in place).
• Your stack is PHP/Composer, ideally Laravel, and you want vendor-aligned error codes and request signing rather than hand-rolling them.
• You value "official SDK" as a liability/ownership signal — when something breaks, you have a vendor to escalate to.
• Your integration needs are conventional: hosted payment page, redirect flows, status polling, refunds.

Look elsewhere when:

• mPAY24 is not your provider — this has no value as a general payment library.
• You need an actively maintained dependency: no release since 2022 means unverified PHP/Laravel compatibility and no recent security patching. Validate in a spike before planning around it.
• You need multi-provider abstraction or failover — use a payment orchestration layer or a framework-agnostic abstraction (e.g., Omnipay-style) instead.
• Your flow is a simple redirect to a hosted page; direct REST calls may be less code and less dependency than an unmaintained wrapper.
• You require audited, SOC2/PCI-scope-reducing libraries with active CVE response — thin vendor SDKs often sit outside that bar anyway.
• You need webhooks, async settlement reconciliation, or modern client-side components that the SDK may not expose.

How to Pitch It (Stakeholders)

To executives: This is the official PHP SDK for mPAY24, an Austrian payment provider — relevant only if we go with that PSP, typically for a DACH-market launch. It is MIT-licensed and free, so the cost is engineering time, not licensing: roughly a few days of integration instead of one to two weeks building the API client ourselves. The trade-off is maturity — low adoption (~13 stars) and no release since 2022 mean we should treat it as a thin adapter we own, not a supported platform. Recommendation: adopt only alongside the mPAY24 commercial decision, isolate it behind our own payments interface, and timebox a compatibility spike against our PHP/Laravel versions.

To engineering: Vendor wrapper around mPAY24's REST API. Wrap it behind an internal PaymentGateway contract from day one; do not let its DTOs reach domain code. Before committing, verify PHP 8.2+/Laravel 10+ support, test coverage, exception/timeout behaviour, and idempotency handling on payment initiation. Add contract tests against the sandbox so a future fork or replacement is a swap, not a rewrite. Watch the dependency for security advisories.