<?php

namespace ChargeForms\Includes;

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Thin registry mapping a gateway id (stored on the payment_method field as
 * `field.gateway`) to the class that implements it. Deliberately NOT built
 * on Includes\Integrations\Abstract_Integration/Integration_Manager — that
 * pattern is "run every configured one after a submission fires" (webhooks,
 * CRM sync); a payment gateway is the opposite shape, exactly one gateway
 * is picked per payment field and called synchronously mid-submission to
 * create/verify a real charge, so a simple id-to-class lookup is the right
 * amount of structure here, not a second dispatch system.
 *
 * Every registered class is expected to expose the same static contract
 * Stripe_Gateway already established (kept static, not instance-based, so
 * existing Stripe_Gateway::method() call sites never had to change):
 *   - calculate_total( array $form, array $submitted_values ): float
 *   - is_configured(): bool
 * plus whatever create/verify methods that gateway's own flow needs
 * (Stripe: create_intent()/retrieve_intent(); PayPal:
 * create_order()/capture_order()) — these aren't identical across gateways
 * because Stripe and PayPal's real payment flows aren't identical (confirm
 * client-side vs. capture server-side), so callers branch on gateway id
 * where the flow itself differs (see SubmissionHandler::verify_payment())
 * rather than forcing a false-common interface over two genuinely
 * different processes.
 *
 * Recurring billing is the one capability that DOES get a real, checked
 * interface (Subscription_Gateway_Interface) rather than another ad-hoc
 * static method — see supports_subscriptions() below and that interface's
 * own doc comment for why one-time-charge flows and subscription flows
 * are treated differently here.
 */
class Gateway_Manager {

	const DEFAULT_GATEWAY = 'stripe';

	private static $gateways = [
		'stripe' => Stripe_Gateway::class,
		'paypal' => Paypal_Gateway::class,
	];

	/** Resolves a stored (or missing) gateway id to a real, known gateway class — always falls back to the default rather than erroring, since every payment_method field saved before PayPal existed has no `gateway` value at all and must keep behaving exactly as it did before. */
	public static function get( $gateway_id ) {
		return self::$gateways[ $gateway_id ] ?? self::$gateways[ self::DEFAULT_GATEWAY ];
	}

	public static function ids(): array {
		return array_keys( self::$gateways );
	}

	/**
	 * Detects recurring-billing capability via the gateway class actually
	 * implementing Subscription_Gateway_Interface, not a hardcoded
	 * `'stripe' === $gateway_id` check — the extensibility seam a future
	 * PayPal-subscriptions or Square gateway plugs into automatically the
	 * moment it implements the interface and registers itself above,
	 * with zero changes needed in SubmissionHandler, RestApi, or the
	 * builder's Field Settings panel (all three call this instead of
	 * naming a gateway).
	 */
	public static function supports_subscriptions( $gateway_id ) {
		return in_array( Subscription_Gateway_Interface::class, class_implements( self::get( $gateway_id ) ) ?: [], true );
	}
}