449 lines
22 KiB
HTML
449 lines
22 KiB
HTML
<title>Payments Feature Survey</title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
|
<link rel="preconnect" href="https://fonts.googleapis.com" />
|
|
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
|
|
<link href="https://fonts.googleapis.com/css2?family=Fraunces:opsz,wght@9..144,400;9..144,500;9..144,600;9..144,700&family=IBM+Plex+Sans:wght@400;500;600&family=IBM+Plex+Mono:wght@400;500&display=swap" rel="stylesheet" />
|
|
|
|
<style>
|
|
:root {
|
|
--paper: #FAFAF7;
|
|
--ink: #1C1C1A;
|
|
--muted: #6B6B63;
|
|
--accent: #2F5D50;
|
|
--accent-soft: #E4EDE9;
|
|
--good: #3F7A5C;
|
|
--good-soft: #E6F0EA;
|
|
--warn: #B8863B;
|
|
--warn-soft: #F5ECDC;
|
|
--miss: #A14B3B;
|
|
--miss-soft: #F5E5E0;
|
|
--hairline: #E4E2DB;
|
|
--card: #FFFFFF;
|
|
}
|
|
|
|
@media (prefers-color-scheme: dark) {
|
|
:root:not([data-theme="light"]) {
|
|
--paper: #17181A;
|
|
--ink: #EDEBE4;
|
|
--muted: #9B9A91;
|
|
--accent: #6FAE97;
|
|
--accent-soft: #1E2C27;
|
|
--good: #6FAE97;
|
|
--good-soft: #1C2B22;
|
|
--warn: #D8A85C;
|
|
--warn-soft: #2E2718;
|
|
--miss: #D97F68;
|
|
--miss-soft: #2E1F1A;
|
|
--hairline: #2C2D2E;
|
|
--card: #1D1F20;
|
|
}
|
|
}
|
|
|
|
:root[data-theme="dark"] {
|
|
--paper: #17181A;
|
|
--ink: #EDEBE4;
|
|
--muted: #9B9A91;
|
|
--accent: #6FAE97;
|
|
--accent-soft: #1E2C27;
|
|
--good: #6FAE97;
|
|
--good-soft: #1C2B22;
|
|
--warn: #D8A85C;
|
|
--warn-soft: #2E2718;
|
|
--miss: #D97F68;
|
|
--miss-soft: #2E1F1A;
|
|
--hairline: #2C2D2E;
|
|
--card: #1D1F20;
|
|
}
|
|
|
|
* { box-sizing: border-box; }
|
|
|
|
body {
|
|
background: var(--paper);
|
|
color: var(--ink);
|
|
font-family: "IBM Plex Sans", ui-sans-serif, system-ui, sans-serif;
|
|
font-size: 16px;
|
|
line-height: 1.55;
|
|
-webkit-font-smoothing: antialiased;
|
|
}
|
|
|
|
.page {
|
|
max-width: 780px;
|
|
margin: 0 auto;
|
|
padding: 72px 24px 96px;
|
|
}
|
|
|
|
header.masthead {
|
|
margin-bottom: 56px;
|
|
}
|
|
|
|
.eyebrow {
|
|
font-family: "IBM Plex Mono", ui-monospace, monospace;
|
|
font-size: 12.5px;
|
|
letter-spacing: 0.08em;
|
|
text-transform: uppercase;
|
|
color: var(--accent);
|
|
margin: 0 0 18px;
|
|
}
|
|
|
|
h1 {
|
|
font-family: "Fraunces", Georgia, serif;
|
|
font-weight: 600;
|
|
font-size: clamp(30px, 5vw, 40px);
|
|
line-height: 1.18;
|
|
letter-spacing: -0.01em;
|
|
margin: 0 0 18px;
|
|
text-wrap: balance;
|
|
max-width: 22ch;
|
|
}
|
|
|
|
.dek {
|
|
color: var(--muted);
|
|
font-size: 16.5px;
|
|
max-width: 62ch;
|
|
margin: 0 0 28px;
|
|
}
|
|
|
|
.summary-strip {
|
|
display: flex;
|
|
gap: 10px;
|
|
flex-wrap: wrap;
|
|
padding-top: 22px;
|
|
border-top: 1px solid var(--hairline);
|
|
}
|
|
|
|
.summary-pill {
|
|
font-family: "IBM Plex Mono", ui-monospace, monospace;
|
|
font-size: 12.5px;
|
|
padding: 6px 12px;
|
|
border-radius: 999px;
|
|
display: flex;
|
|
align-items: baseline;
|
|
gap: 6px;
|
|
}
|
|
.summary-pill b { font-size: 13.5px; }
|
|
.summary-pill.have { background: var(--good-soft); color: var(--good); }
|
|
.summary-pill.partial { background: var(--warn-soft); color: var(--warn); }
|
|
.summary-pill.missing { background: var(--miss-soft); color: var(--miss); }
|
|
|
|
section.category {
|
|
margin-bottom: 52px;
|
|
}
|
|
|
|
.category-head {
|
|
display: flex;
|
|
gap: 16px;
|
|
align-items: baseline;
|
|
margin-bottom: 6px;
|
|
}
|
|
|
|
.numeral {
|
|
font-family: "Fraunces", Georgia, serif;
|
|
font-weight: 500;
|
|
font-size: 15px;
|
|
color: var(--accent);
|
|
font-variant-numeric: tabular-nums;
|
|
flex: none;
|
|
width: 2ch;
|
|
}
|
|
|
|
h2 {
|
|
font-family: "Fraunces", Georgia, serif;
|
|
font-weight: 600;
|
|
font-size: 22px;
|
|
margin: 0;
|
|
letter-spacing: -0.01em;
|
|
}
|
|
|
|
.category-note {
|
|
color: var(--muted);
|
|
font-size: 14.5px;
|
|
margin: 0 0 22px 34px;
|
|
max-width: 58ch;
|
|
}
|
|
|
|
.rows {
|
|
margin-left: 34px;
|
|
border-top: 1px solid var(--hairline);
|
|
}
|
|
|
|
.row {
|
|
padding: 16px 0;
|
|
border-bottom: 1px solid var(--hairline);
|
|
}
|
|
|
|
.row-head {
|
|
display: flex;
|
|
justify-content: space-between;
|
|
align-items: center;
|
|
gap: 16px;
|
|
}
|
|
|
|
.feature-name {
|
|
font-weight: 500;
|
|
font-size: 15.5px;
|
|
}
|
|
|
|
.chip {
|
|
font-family: "IBM Plex Mono", ui-monospace, monospace;
|
|
font-size: 11.5px;
|
|
letter-spacing: 0.04em;
|
|
text-transform: uppercase;
|
|
padding: 3px 10px;
|
|
border-radius: 999px;
|
|
flex: none;
|
|
white-space: nowrap;
|
|
}
|
|
.chip.have { background: var(--good-soft); color: var(--good); }
|
|
.chip.partial { background: var(--warn-soft); color: var(--warn); }
|
|
.chip.missing { background: var(--miss-soft); color: var(--miss); }
|
|
|
|
.grounding {
|
|
color: var(--muted);
|
|
font-size: 13.5px;
|
|
margin-top: 6px;
|
|
line-height: 1.5;
|
|
max-width: 64ch;
|
|
}
|
|
|
|
code {
|
|
font-family: "IBM Plex Mono", ui-monospace, monospace;
|
|
font-size: 12.5px;
|
|
background: var(--accent-soft);
|
|
color: var(--accent);
|
|
padding: 1px 5px;
|
|
border-radius: 4px;
|
|
}
|
|
|
|
footer {
|
|
margin-top: 64px;
|
|
padding-top: 24px;
|
|
border-top: 1px solid var(--hairline);
|
|
color: var(--muted);
|
|
font-size: 13px;
|
|
}
|
|
|
|
footer .compiled {
|
|
font-family: "IBM Plex Mono", ui-monospace, monospace;
|
|
font-size: 12px;
|
|
margin-bottom: 10px;
|
|
}
|
|
|
|
footer p {
|
|
margin: 0 0 8px;
|
|
max-width: 62ch;
|
|
}
|
|
|
|
footer p:last-child { margin-bottom: 0; }
|
|
|
|
@media (max-width: 560px) {
|
|
.category-note, .rows { margin-left: 0; }
|
|
.category-head { gap: 10px; }
|
|
}
|
|
</style>
|
|
|
|
<div class="page">
|
|
|
|
<header class="masthead">
|
|
<p class="eyebrow">boboko-core · competitive gap survey · 03</p>
|
|
<h1>What payments elsewhere can do that boboko can't yet</h1>
|
|
<p class="dek">
|
|
Lunar's payment layer (<code>Lunar\Facades\Payments</code>, <code>Transaction</code>, the offline
|
|
driver) is wired for a single "pay on delivery / bank transfer" flow. Everything downstream of
|
|
that — cards, wallets, saved methods, self-service refunds, retries — is either scaffolded in
|
|
Lunar core and unused here, or absent from the stack entirely. This is a research survey, not a
|
|
build plan.
|
|
</p>
|
|
<div class="summary-strip">
|
|
<span class="summary-pill have"><b>4</b> have</span>
|
|
<span class="summary-pill partial"><b>9</b> partial</span>
|
|
<span class="summary-pill missing"><b>14</b> missing</span>
|
|
</div>
|
|
</header>
|
|
|
|
<section class="category">
|
|
<div class="category-head">
|
|
<span class="numeral">01</span>
|
|
<h2>Payment method breadth</h2>
|
|
</div>
|
|
<p class="category-note">boboko currently ships one payment type: cash-in-hand via the offline driver. Every card/wallet/BNPL path below is theoretically pluggable but has zero live implementation.</p>
|
|
<div class="rows">
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Offline / pay-on-account</span><span class="chip have">have</span></div>
|
|
<div class="grounding">The only configured type in <code>config/lunar/payments.php</code> (3dealer's published copy): <code>'cash-in-hand' => ['driver' => 'offline', 'authorized' => 'payment-offline']</code>, backed by <code>Lunar\PaymentTypes\OfflinePayment</code>.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Card payments (Stripe/other gateway)</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding"><code>lunarphp/stripe</code> is not present in either <code>boboko-core/vendor/lunarphp</code> or <code>3dealer/vendor/lunarphp</code>, and not listed in either <code>composer.json</code>. <code>docs/lunar.md</code>'s Stripe section documents Lunar's general capability, not something wired into this project.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Digital wallets (Apple Pay, Google Pay, Shop Pay)</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">Depends entirely on a card gateway (Stripe Payment Request Button or similar) that isn't installed. Shopify bundles Apple Pay, Google Pay, and Shop Pay as one-tap checkout by default.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Buy-now-pay-later (Klarna, Afterpay, Affirm)</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No BNPL driver or config entry anywhere in the repo. Shopify bundles Klarna natively in eligible regions with Pay-in-4, Pay-Later, and financing tiers; WooCommerce and PrestaShop both offer it as installable gateway plugins.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Bank transfer / open banking (SEPA, Pay by Bank)</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">Not represented as a distinct payment type; only the generic cash-in-hand offline flow exists, which is manual reconciliation rather than an automated bank-transfer rail.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Crypto / stablecoin checkout</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No driver, no research finding of it being used in this stack. Industry-wide it's still marginal — stablecoin payment volume is roughly 0.02% of global payments in 2026 per Nuvei's trend report — so this is low-priority even elsewhere.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Pluggable driver architecture for adding methods</span><span class="chip have">have</span></div>
|
|
<div class="grounding"><code>Lunar\Managers\PaymentManager</code> extends Laravel's <code>Manager</code>; <code>Payments::extend('custom', fn ($app) => ...)</code> registers a new driver, and any class extending <code>Lunar\PaymentTypes\AbstractPayment</code> implementing <code>authorize()</code>/<code>capture()</code>/<code>refund()</code> plugs in. The scaffolding is solid — nothing beyond offline is plugged into it yet.</div>
|
|
</div>
|
|
|
|
</div>
|
|
</section>
|
|
|
|
<section class="category">
|
|
<div class="category-head">
|
|
<span class="numeral">02</span>
|
|
<h2>Capture, refund & transaction lifecycle</h2>
|
|
</div>
|
|
<p class="category-note">The core primitives (intent/capture/refund, partial amounts, transaction chaining) exist in Lunar and are exposed in the Filament admin — but nothing calls them outside cash-in-hand, and none of it is customer-facing.</p>
|
|
<div class="rows">
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Authorize / capture / refund contract</span><span class="chip have">have</span></div>
|
|
<div class="grounding"><code>Lunar\Base\PaymentTypeInterface</code> defines <code>authorize()</code>, <code>capture(Transaction $t, $amount)</code>, <code>refund(Transaction $t, int $amount, $notes)</code>; <code>Transaction::capture()</code>/<code>refund()</code> forward to the transaction's own <code>driver()</code> via <code>Payments::driver($this->driver)</code>.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Manual vs. automatic capture policy</span><span class="chip partial">partial</span></div>
|
|
<div class="grounding">The interface supports separate authorize/capture steps (intent vs. capture transaction types), but <code>OfflinePayment::capture()</code> just returns <code>new PaymentCapture(true)</code> unconditionally — there's no real deferred-capture gateway wired up to exercise the distinction.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Partial capture</span><span class="chip partial">partial</span></div>
|
|
<div class="grounding">Admin Filament action passes an arbitrary <code>$data['amount']</code> to <code>$transaction->capture(bcmul($data['amount'], $record->currency->factor))</code> in <code>ManageOrder.php</code> — the plumbing supports partial amounts, but only staff can trigger it, and only against a real (non-offline) driver would it mean anything.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Partial / staged refunds</span><span class="chip have">have</span></div>
|
|
<div class="grounding">Same file: the "refund" Filament action computes <code>$response = $transaction->refund(bcmul($data['amount'], ...), $data['notes'])</code>, and <code>isPartiallyRefunded()</code> / order status logic (<code>partial-refund</code>, <code>refunded</code>) compares <code>refundTotal</code> against <code>captureTotal</code>/<code>intentTotal</code>. This genuinely works today through the offline driver's no-op <code>refund()</code>.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Multiple payment attempts per order</span><span class="chip partial">partial</span></div>
|
|
<div class="grounding"><code>Transaction.parent_transaction_id</code> chains captures to intents and refunds to captures, and nothing in the model stops multiple transaction rows per order — but no code path in this repo actually retries a failed attempt with a second transaction; it's schema support, not a driven flow.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Transaction audit trail</span><span class="chip have">have</span></div>
|
|
<div class="grounding"><code>Lunar\Observers\TransactionObserver::created()</code> logs every transaction (amount, type, status, card_type, last_four, reference, notes) via Spatie activity log automatically — this is real and unconditional, independent of driver.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Webhook handling for async payment events</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">Lunar's Stripe package registers a <code>stripe/webhook</code> route, but that package isn't installed here, so there is no webhook endpoint of any kind in this project today.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Payment attempt events for downstream hooks</span><span class="chip have">have</span></div>
|
|
<div class="grounding"><code>Lunar\Events\PaymentAttemptEvent</code> is dispatched from <code>OfflinePayment::authorize()</code> with the resulting <code>PaymentAuthorize</code> DTO — a real, listenable event, though only one driver currently fires it.</div>
|
|
</div>
|
|
|
|
</div>
|
|
</section>
|
|
|
|
<section class="category">
|
|
<div class="category-head">
|
|
<span class="numeral">03</span>
|
|
<h2>Customer-facing payment experience</h2>
|
|
</div>
|
|
<p class="category-note">Everything a shopper would touch directly — saved cards, one-click repeat purchase, self-service refunds — is absent. Lunar's payment layer is staff/checkout-oriented, not account-oriented.</p>
|
|
<div class="rows">
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Saved payment methods on customer account</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No vault/tokenization model exists anywhere in <code>Lunar\Models</code> — no <code>PaymentMethod</code>/<code>Card</code> model, no field on <code>Customer</code>. 2026 trend research (Nuvei, Checkout.com) treats network-tokenized saved cards as baseline for one-click checkout.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">One-click repeat purchase</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">Depends on saved payment methods, which don't exist. No "reorder" or "buy again" affordance found in boboko-core or 3dealer.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Customer self-service refund requests</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">The only refund entry point is the Filament staff action in <code>ManageOrder.php</code> (<code>Actions\Action::make('refund')</code>), gated behind admin auth. WooCommerce/PrestaShop ecosystems commonly expose a customer-initiated return/refund request flow; nothing equivalent exists here.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Split / partial payment plans (pay-in-installments at checkout)</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">Distinct from BNPL-as-a-gateway: this is a native "split into N charges" checkout option, seen as marketplace split-payment modules in the PrestaShop ecosystem. No equivalent concept in Lunar's cart/order/payment pipeline.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">3D Secure / SCA authentication</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">3DS is a property of the card gateway integration (e.g. Stripe PaymentIntents), which isn't installed. WooPayments explicitly advertises 3DS/SCA compatibility with visible card-brand + last-four confirmation as a baseline expectation in 2026.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Fraud detection / risk scoring</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No fraud-scoring hook in <code>PaymentTypeInterface</code> or the offline driver. <code>getPaymentChecks()</code> exists as an extension point (<code>Lunar\Base\DataTransferObjects\PaymentChecks</code>, an iterable of pass/fail <code>PaymentCheck</code> DTOs) but <code>AbstractPayment::getPaymentChecks()</code> just returns an empty collection — real fraud tooling (Stripe Radar-style) isn't behind it.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Payment check / validation extension point</span><span class="chip partial">partial</span></div>
|
|
<div class="grounding"><code>Transaction::paymentChecks()</code> → driver's <code>getPaymentChecks($transaction)</code> is real, typed infrastructure for surfacing checks (e.g. "AVS matched") in the admin UI — but the default implementation is a no-op, so nothing populates it today.</div>
|
|
</div>
|
|
|
|
</div>
|
|
</section>
|
|
|
|
<section class="category">
|
|
<div class="category-head">
|
|
<span class="numeral">04</span>
|
|
<h2>Currency, subscriptions & recurring billing</h2>
|
|
</div>
|
|
<p class="category-note">Lunar's multi-currency model covers pricing display, not multi-currency payment settlement; recurring billing/dunning has no representation at all.</p>
|
|
<div class="rows">
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Multi-currency pricing display</span><span class="chip have">have</span></div>
|
|
<div class="grounding"><code>Lunar\Models\Currency</code> (code, exchange_rate, decimal_places, default) with <code>sync_prices</code>-gated conversion, documented in <code>docs/lunar.md</code> "Channels and Currencies" — this is genuinely wired, cart/pricing layer already uses it.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Multi-currency payment processing (charge in customer's currency)</span><span class="chip partial">partial</span></div>
|
|
<div class="grounding">Pricing can display and calculate in any configured currency, but no payment driver in this project actually settles a charge — so whether a real gateway would charge in-currency is untested; the pricing half is there, the processing half isn't proven.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Recurring billing / subscriptions</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No subscription model, no recurring-charge scheduler anywhere in <code>Lunar\Models</code> or boboko-core. This is a one-time-purchase order/cart model end to end.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">Failed-payment retry / dunning</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No retry scheduling, no dunning email sequence, no soft-decline handling anywhere in the payment layer — there's nothing to retry against since there's no recurring billing and no live gateway. WooPayments' dunning (1-3 day delayed retry on soft declines) is the comparison point.</div>
|
|
</div>
|
|
|
|
<div class="row">
|
|
<div class="row-head"><span class="feature-name">PCI compliance / tokenized card storage</span><span class="chip missing">missing</span></div>
|
|
<div class="grounding">No card data is collected or stored anywhere in this codebase (offline driver never touches card fields), so there's no PCI-scope exposure today — but also no tokenized-vault capability to build saved cards or 3DS on top of when a real gateway is added.</div>
|
|
</div>
|
|
|
|
</div>
|
|
</section>
|
|
|
|
<footer>
|
|
<p class="compiled">Compiled 2026-08-28 · boboko-core / docs</p>
|
|
<p>Section 01 (driver architecture) and section 02 (transaction lifecycle, refund/capture, observer, events) are grounded in direct reads of <code>vendor/lunarphp/core/src/{Managers,PaymentTypes,Models,Observers,Events,Base}</code> and <code>vendor/lunarphp/lunar/src/Filament/Resources/OrderResource/Pages/ManageOrder.php</code>, plus the published <code>config/lunar/payments.php</code> in 3dealer — not from <code>docs/lunar.md</code> alone, which was cross-checked and found to describe Lunar's general Stripe capability rather than anything installed in this project.</p>
|
|
<p>Sections 03 and 04, and the competitive framing throughout, draw on 2026 web research covering Shopify, WooCommerce/WooPayments, and PrestaShop payment modules, plus general industry trend reporting (Nuvei, Checkout.com, Mastercard). Those claims are marked by comparison language ("Shopify bundles...", "WooPayments advertises...") rather than citation to this repo.</p>
|
|
</footer>
|
|
|
|
</div>
|