- How do I install and configure cable8mm/laravel-portone?
- Install it with composer require cable8mm/laravel-portone, then publish the package config and set your PortOne store ID, channel keys, and API secret in the environment. The service provider is auto-discovered in standard Laravel apps. After that you can initiate a payment from any model that uses the package's Cashier-style interface.
- Which Laravel and PHP versions does laravel-portone support?
- The package targets Laravel 9, 10, and 11 on PHP 8.1 or newer, which is the matrix the technical assessment treats as feasible. Confirm the exact constraints in the package's composer.json before installing, because pre-1.0 releases can tighten or widen support without a major version bump. If you are on an older Laravel or PHP version, test in a branch first.
- Can I attach PortOne payments to any Eloquent model like Laravel Cashier?
- Yes. The package is designed around a Laravel Cashier-style interface, so you can attach payment behavior to any Eloquent model rather than being locked to a single User or Order class. That keeps your domain model intact and lets you decide which entity owns the payment relationship. You still need your own order-state fields and business rules.
- How does the v0.6.0 mobile redirect checkout flow work?
- In v0.6.0 the package adds a single redirect checkout flow for mobile PG windows: your app initiates the payment, the customer is sent to the PortOne/PG window, and they return to a callback URL where the payment is verified. It is meant for mobile browsers where popups and iframes are unreliable. Treat it as an integration component with a route surface, not a pure HTTP library.
- Is the return URL enough to confirm a PortOne payment succeeded?
- No. Redirect-based checkout is lossy because users can close the tab, switch apps, or never come back, so the return URL should be treated as UX only. The authoritative confirmation should come from the PortOne webhook plus your own verification call. Build your order state machine so a missing return does not leave an order stuck or falsely marked paid.
- Does laravel-portone handle PortOne webhook signature verification?
- The package is positioned as webhook-ready, but the assessment flags signature verification as part of the scaffolding you must budget for and asks whether the package provides it. Verify this in the docs before going live. In practice, plan to implement signature verification at your webhook endpoint and reject unsigned or stale payloads.
- Is laravel-portone safe for production given it is pre-1.0?
- Treat it as pre-1.0 software on a revenue-critical path. The 0.x semver allows breaking changes in minor releases, and the project has a single maintainer, so pin an exact version and read release diffs before upgrading. Keep a thin internal adapter around the package so you can fork it or swap to direct PortOne REST calls without a rewrite.
- How do I prevent duplicate PortOne payments or add idempotency?
- The assessment explicitly asks whether the verification call has an idempotency key or duplicate-payment guard, so do not assume it is built in. Add your own idempotency key per order and make your verification and webhook handlers safe to retry. Persist the PortOne transaction ID and enforce a unique constraint or state transition check.
- What changed from 0.5.x to 0.6.0 and how do I upgrade?
- v0.5.0 to v0.6.0 is a minor bump under 0.x semver, which permits breaking changes, and the release notes point to a docs PR about changing the force-redirect flow. Read the diff for PR #46 and test the redirect behavior in a staging environment before upgrading. Pin the new version only after you confirm whether force-redirect is superseded, coexists behind a config flag, or is deprecated.
- Which Korean PG channels work with the mobile redirect flow, and should I use the REST API directly?
- The assessment says it is unclear whether the mobile redirect path covers all PortOne channels or only specific PGs such as KakaoPay, NaverPay, Toss, and card acquirers, so confirm channel coverage before relying on it for the full mobile funnel. If a channel is unsupported, fall back to PortOne's standard checkout or call the PortOne V2 REST API directly. Because the package is a thin wrapper, a direct REST integration is a realistic fallback and a good contingency plan.