Kevin
68d230d4e5
Rueckmeldung der Buchhaltung und des Stripe-Calls (dev/2026-08-26-stripe/): Stripe kannte bisher nur die E-Mail des Kunden, Zahlungen waren im Dashboard weder ueber die Bestell- noch ueber die Rechnungsnummer auffindbar, und ein Zahlungseingang mit falschem Verwendungszweck zwang die Buchhaltung dazu, die Rechnung von Hand zu schreiben. - SE1: Der Checkout haengt einen Stripe-Customer mit Name, E-Mail und Rechnungsanschrift an die Session (customer statt customer_email); die ID liegt an shopping_users und wird wiederverwendet. Namensformat "Vorname Nachname (Firma)", reine Firmenkunden unter der Firma. Faellt die Customer-Anlage aus, laeuft der Checkout auf dem bisherigen Weg weiter. DSGVO-Loeschungen entfernen jetzt auch das Customer-Objekt; die Charges bleiben als Buchungsbeleg bestehen. - SE2: StripeMetadataBuilder als einzige Quelle fuer Metadaten und die description (Bestellnummer, Referenz, Kundenname) - damit greift die Dashboard-Suche, die bisher nichts Lesbares zu fassen bekam. - SE3: Die Rechnungsnummer entsteht erst nach der Zahlung und wird daher per Job am PaymentIntent nachgetragen (Vorab-Reservierung wuerde Luecken im Nummernkreis erzeugen). stripe:backfill-invoice-metadata traegt sie rueckwirkend ab dem Go-Live 2026-07-10 nach. - SE4: Neuer Admin-Button "Zahlungseingang erfassen" an jeder unbezahlten Bestellung - bisher gab es ihn nur bei Rechnungskauf, und er setzte nur paid, ohne Rechnung, Punkte, Abo-Aktivierung oder Mail. Der neue Weg laeuft durch paymentStatusPaidAction, verlangt den Verwendungszweck als Beleg und laesst einen abweichenden Betrag nur mit ausdruecklicher Bestaetigung zu. - S6.4 (aus dem Juli-Plan vorgezogen): stripe:sync-payment-status gleicht offene Zahlungen aktiv gegen die API ab. Aufgefallen beim Testlauf - ein nie zugestellter Webhook war bisher nicht reparierbar, das Geld lag bei Stripe waehrend die Bestellung auf offen stand. Laeuft stuendlich im Scheduler. - 110 Tests (Pest) fuer alle Pfade, Stripe-Client durchgehend gemockt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
48 lines
1.5 KiB
PHP
48 lines
1.5 KiB
PHP
<?php
|
|
|
|
namespace App\Jobs;
|
|
|
|
use App\Models\ShoppingPayment;
|
|
use App\Models\UserInvoice;
|
|
use App\Services\Payment\Stripe\StripeInvoiceReferenceService;
|
|
use Illuminate\Bus\Queueable as BusQueueable;
|
|
use Illuminate\Contracts\Queue\ShouldQueue;
|
|
use Illuminate\Foundation\Bus\Dispatchable;
|
|
use Illuminate\Queue\InteractsWithQueue;
|
|
use Illuminate\Queue\SerializesModels;
|
|
use Illuminate\Support\Facades\Log;
|
|
|
|
/**
|
|
* Trägt die MIVITA-Rechnungsnummer am Stripe-PaymentIntent nach
|
|
* (Plan dev/2026-08-26-stripe/, Phase SE3).
|
|
*
|
|
* Asynchron, weil der Auslöser im Webhook-Paid-Pfad sitzt: ein API-Call zu
|
|
* Stripe darf die Antwortzeit des Webhooks nicht belasten und erst recht
|
|
* nicht dazu führen, dass Stripe den Webhook als fehlgeschlagen wertet.
|
|
*/
|
|
class SyncStripeInvoiceReference implements ShouldQueue
|
|
{
|
|
use BusQueueable, Dispatchable, InteractsWithQueue, SerializesModels;
|
|
|
|
public $tries = 3;
|
|
|
|
public $timeout = 30;
|
|
|
|
public function __construct(
|
|
public ShoppingPayment $shoppingPayment,
|
|
public UserInvoice $userInvoice,
|
|
) {}
|
|
|
|
public function handle(StripeInvoiceReferenceService $service): void
|
|
{
|
|
$service->sync($this->shoppingPayment, $this->userInvoice);
|
|
}
|
|
|
|
public function failed(\Throwable $e): void
|
|
{
|
|
Log::channel('stripe')->error('Rechnungsnummer konnte nicht an Stripe übertragen werden: '.$e->getMessage(), [
|
|
'shopping_payment_id' => $this->shoppingPayment->id,
|
|
'user_invoice_id' => $this->userInvoice->id,
|
|
]);
|
|
}
|
|
}
|