HSLG Media

PaymentSchemaV4.php

PaymentSchemaV4.php

Source file: backend/database/migrations/PaymentSchemaV4.php

Module: backend-database

Size: 58 lines

SHA-256: 2955f65f7c969664d2a4d133de87c565b1ed7042d187b151ca407b83246dc4ae

Responsibility

Implements repositories, schema definitions and migration contracts; MariaDB owns originating customer record time.

Declared entry points

  • PaymentSchemaV4 — source line 10.
  • VERSION — source line 12.
  • statements — source line 13.

Imports and dependencies

  • Line 4: use Hslg\Backend\Database\TableNames;

Behaviour and audit locations

  • Line 7: * as settlement without official Stripe signature + server-side retrieval.
  • Line 8: * No live Stripe route is enabled by this schema alone.
  • Line 17: $events=$names->get('stripe_webhook_events');
  • Line 25: created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  • Line 26: updated_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
  • Line 33: stripe_intent_id varchar(128) NULL,
  • Line 39: created_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
  • Line 40: updated_at datetime(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),

Payment-related storage foundation

This schema layer supports later server pricing and payment evidence. It is not by itself an enabled Stripe settlement implementation. Changes here need a migration/rollback plan, strict provider reference uniqueness, venue association, audit retention and verification that card secrets are not stored. Successful migration must be proven against the intended MariaDB version.

Relationship to the system

This page is the file-level source reference, not the architecture rationale. Read the module explanation, the corresponding architecture decision and user guide before changing behaviour. Names and line locations above are extracted from this exact source version; they are reference points, not proof that an external service or a phone feature works.

Change verification

Review the entry points and errors in this file, then run the module’s associated tests, source dependency gate, history gate and documentation coverage check. If the file changes an API response, user interaction, data model, deployment or third-party dependency, revise those human explanations and disaster recovery/licensing when relevant. Do not infer actual native or external API operation from source presence.