Fix: Stripe Intents Table is a Lunar Table, so needs a prefix. This is covered by the Lunar\Base\Migration

database/migrations/2026_09_03_000002_add_context_to_stripe_payment_intents.php

@@ -1,8 +1,8 @@
 <?php
 
-use Illuminate\Database\Migrations\Migration;
 use Illuminate\Database\Schema\Blueprint;
 use Illuminate\Support\Facades\Schema;
+use Lunar\Base\Migration;
 
 /**
  * lunarphp/stripe's own stripe_payment_intents table already correlates a
@@ -19,12 +19,20 @@ use Illuminate\Support\Facades\Schema;
  *     were called with — needed to dispatch Payment events with the
  *     correct $type in handleCallback(), which otherwise has no way to
  *     know it (a webhook payload doesn't carry it).
+ *
+ * Extends Lunar\Base\Migration (not the plain base Migration) so $this->prefix
+ * resolves the SAME table-prefix config every Lunar-owned table uses
+ * (config('lunar.database.table_prefix')) — the vendor migration that
+ * creates this table (lunarphp/stripe's create_stripe_payment_intents_table)
+ * already does this, so a store running with a non-default prefix (this
+ * one runs with 'lunar_') would otherwise have this migration fail against
+ * a table name that doesn't exist.
  */
 return new class extends Migration
 {
     public function up(): void
     {
-        Schema::table('stripe_payment_intents', function (Blueprint $table) {
+        Schema::table($this->prefix.'stripe_payment_intents', function (Blueprint $table) {
             $table->json('context')->nullable()->after('status');
             $table->string('payment_type')->nullable()->after('context');
         });
@@ -32,7 +40,7 @@ return new class extends Migration
 
     public function down(): void
     {
-        Schema::table('stripe_payment_intents', function (Blueprint $table) {
+        Schema::table($this->prefix.'stripe_payment_intents', function (Blueprint $table) {
             $table->dropColumn(['context', 'payment_type']);
         });
     }